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[57] 



ABSTRACT 



A system and method for paying bills without requiring 
interaction with the payors disclosed. The system includes a 
payor control interface, a communications interface, a bill 
generator, and a TCF message generator. The bill generator 
generates bill records from payor and payee information 
stored within the system for recurring bills. The bill gen- 
erator may also generate bill records from the payor and 
payee information and from bill data messages received 
from payees. The generated bill records are used by the TCF 
message generator to generate the EFT messages for trans- 
ferring funds electronically between payors and payees. 
Payors may alter the payment amount and date for a bill as 
well as reverse payment of a bill already paid. Payees are 
also able to alter recurring bill records or may present bill 
data so that bill records reflecting variable obligation 
amounts may be generated. 
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SYSTEM AND METHOD FOR PAYING BILLS payee. Single/multiple payee category status is usually 

AND OTHER OBLIGATIONS INCLUDING determined from the perspective of the payor. Positive pay 

SELECTIVE PAYOR AND PAYEE systems, operated by a third party, are usually associated 

CONTROLS mu Mpl e payees. Negative pay systems are usually 

5 associated with a single payee. Each of these sub-categories 

. . e v t - « Mrt may be further sub-divided into additional categories such as 

This is a continuation application ot application bet. No. J . - ... • • uc^^i n „A 

M «««i £i j t i inn* lieu* kt zaaq electronic/paper, fixed/variable, provisional/final and 

08/253^64 filed on Jun. 3, 1994, now U.S. Pat. No. 5,649, ar t'al/fiill 

Sy^S^ ^ electronic/paper subcategory is usually used to 

AND OTHER OBLIGATIONS INCLUDING SELECTIVE define g m ^ principally utilizes electronic data 

PAYOR AND PAYEE CONTROLS. io messages t0 txans{eT while paper systems typically use 

ttici n nn tuc rwucMnnw written instruments for this purpose. The fixed/variable 

HbLD Ot I Hfc IN vtw 1 1UN sub-category usually refers to whether the amount of the bill 

This invention relates to systems for paying bills or other is fixed or varies for each billing cycle. Provisional/final 

voluntary or involuntary obligations of payors, and, more sub-category typically indicates whether the payment action 

particularly, to systems that interact with payors or payees. 15 by a payor may be reversed after payment is tendered. 

Finally, the partial/full sub-category defines whether the 

BACKGROUND OF THE INVENTION payor may submit less than the full amount of the payee's 

Systems that facilitate the payment of bills are weU ^ t 
known. While these systen* utdize a variety of components 2Q ^ traditional £ ve action bm paymcnl situation 
to implement a number of different procedures, they all QCCUrs where the payorj after becoming aware of the con- 
possess some drawback that limits the flexibility of the of me m ^ lakes positive action l0 pay me biU by 
system. To understand these various systems and their ma iliog payment documentation back to the payee along 
limitations, an explanatory background discussion is help- ^ a check ^ money order, or other payment instrument, by 
ful* 25 paying the b ill in person at the payee's facilities, or by 

Bill payments usually involve at least two parties, a payor paying the bill in person at an appropriate financial institu- 

and a payee. A payee is a person or entity that receives cash, tion or other third party agent of the payee. Regardless of the 

government tender or other acceptable tender from a payor, method, the payor is required to take positive action to pay 

to satisfy a bill for goods, services or obligations rendered or eacQ bai, even jf me bfli ^ f or the same amount and it recurs 

to be rendered to the payor or other persons. Obligations 30 mon th after month. ft>sitive action bill payment has a 

may be any type of debt owed to another and include such number of disadvantages, including its labor intensive 

items as voluntary payor donations. A payor is the person or nature resulting from the various manual processes and 

other entity that provides the funds or tender for such bill procedures a payor performs to implement it and the rela- 

payment on behalf of itself or others. Abill may be presented uVely high costs in invoice preparation, delivery, check 

at regular or irregular time intervals, may be oral or in a 35 charges, and check clearing processes for the payee, 

written format, and may take the form of a voluntary or Other positive bill payment arrangements have been 

involuntary obligation. directed toward addressing some of the above mentioned 

In most situations, the payee has the responsibility to disadvantages. One such arrangement includes utilizing bills 

determine the amount and due data for payment of a bill. and invoices which comprise a detachable stub portion, * 

Voluntary donations and bill payments of this nature are 40 which, when returned to the payee, may be used to initiate 

typical exceptions to this rule. If a bill is presented in written an electronic funds transfer. Such systems have been imple- 

form it is also usually the responsibility of the payee to mented in certain European countries as a single document 

provide for delivery of the bill to the payor. This can be billing/bill paying procedure, however, these documents 

accomplished either directly between the payor and payee or often do not provide the payee with a negotiable instrument 

indirectly through such third parties as the postal service. 45 upon receipt, and generally do not meet the requirements of 

Once a bill is delivered to the payor it is usually the the check clearing processes of the Federal Reserve System 

responsibility of the payor to deliver payment to the payee. in the United States. Such systems and related single docu- 

This process usually involves one or more third parties. For ment financial data processing procedures are described in 

example, if a check is deposited with the postal service it is U.S. Pat. No. 5,121,945, which issued to E. Thomson et al. 

delivered to a payee which relays it to a bank and the 50 on Jun. 16, 1992. 

banking system is used to collect the payment. In its simplest [ 0 the Thomson et al. patent, the disadvantages of the 

form bill payment consists of the payor personally present- European type systems are overcome with a single docu- 

ing cash to the payee. ment described as being generated by the supplier of goods 

Bill payment may be classified into two very general or services which includes a bill, a maintenance section (to 

categories, positive and negative. Positive bill payment 55 allow for payment changes or to select an option among 

require the payor to "do something" or take a positive action conventional payment methods), and a pre-printed check 

before bill payment is performed. For example, positive which may be utilized by the payor as a fully qualified 

action includes such methods as delivering cash or checks to negotiable instrument for payment of the debt. To pay a bill, 

a payee or authorizing payment of a bill by a third party by a payor simply signs the check and returns it to the supplier, 

using a personal computer or telephone. Positive payment 60 without writing a separate personal check or implementing 

systems also include those in which a payor specifies a other alternate payment procedures. However, this system 

payment action on one date which is implemented on requires positive action by the payee to present each bill to 

another date. Negative action or negative bill payment a payor and requires action by the payee to initiate bill 

requires the payor to "do nothing" in order to pay a bill. Io payment. This system follows relatively standard check 

other words, the payor does something to "stop" a bill from 65 payment and clearance procedures once the instrument is 

being paid. Each category may be further divided into the directed to the payor's financial institution. The patent 

additional sub-categories of single payee and multiple teaches the use of such a system with a single payee. 
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In an effort to further address these limitations, various 
financial establishments have provided their customers with 
the option of paying variable and fixed bills electronically. 
These systems are typically positive action systems in which 
the customer usually initiates payment by communicating 
with the system via an authorized automated teller machine 
(ATM) or telephone. Systems that permit a payor to autho- 
rize payment on one date through such communication with 
the actual payment being performed on a second date are 
still classified as positive systems because the payor must 
take action to pay each bill. Typically, a system of this type 
requires that the payor's and payee's financial institutions 
communicate with the system. Some ATM bill paying sys- 
tems have required that the actual bill be supplied to the 
payor by the payee to ensure proper payment. Telephone bill 
paying systems are somewhat more automated but still 
require the payor to enter through a telephone keypad or 
computer keyboard most of the critical billing information 
such as payor identification, bill amount, payee code or 
account number, etc. While these systems offer a payor 
access to multiple payees and may facilitate bill paying by 
debiting a payor's account and crediting the appropriate 
payee's account, the payment mechanisms require substan- 
tial human interaction for each bill. This interaction is 
required for each bill presented in each billing cycle, even if 
the obligation represented by the bill is a fixed recurring 
debt. While these systems may permit a payor to cancel a bill 
payment action entered by a payor within a predetermined 
waiting period, these systems do not permit a payor to 
reverse a bill payment once processing of the bill payment 
action has commenced. 

Other positive action bill payment schemes have been 
developed whereby a subscriber (i.e., payor) obtains special 
communications devices and/or hardware to pay bills elec- 
tronically from the payor's home. Such user initiated remote 
access systems include CheckFree, a personal computer 
based bill paying service available from CheckFree Corpo- 
ration of Columbus, Ohio, and On-line Banker Service 
offered by On-Line Resources, Ltd. of Washington, D.C. 
Other similar services are mentioned in the background 
section of U.S. Pat. No. 5,283,829, which issued to M. 
Anderson on Feb. 1, 1994. 

The Anderson patent describes billing equipment which 
generates a bill with a unique approval number. Once a 
subscriber receives the bill, he or she may approve the 
payment via an interactive voice response unit by using the 
unique approval number for that particular payment This 
procedure, however, requires the service or goods provider 
(i.e., the payee), to use specialized equipment to generate 
each invoice with its unique approval number. The sub- 
scriber then positively initiates each particular payment in a 
manner similar to the electronic funds transfer procedures of 
various other systems previously available, with the excep- 
tion that sensitive account numbers or other personal infor- 
mation are not required to implement payment of the par- 
ticular bill. Similarly, the On-Line Resources method and 
system mentioned above for remote distribution of financial 
services is described in U.S. Pat. No. 5,220,501 as a positive 
payment system, wherein the user must input payment 
information for each particular debt to be paid. 

Finally, U.S. Pat. No. 4,484,304, which issued to R. 
Anderson et al., describes a transaction execution system 
similar to a variety of automatic teller machine (ATM) 
networks which allow for remote banking, including pay- 
ment of particular bills and invoices of participant payees. 
While the Anderson et al. system appears to offer an alleged 
improvement to conventional ATM networks by allowing 
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multiple financial institutions to use the same host and 
remote terminals, it suffers many of the same shortcomings 
of other prior systems, including a requirement that specific 
payments must be manually entered by the user. There is 
5 also no provision for reversal of payments after they have 
been made. 

Although there have been certain variations on the posi- 
tive action bill payment procedures and systems, these 
arrangements still require the payor to take positive action to 

to initiate payment of the bill even if the payor receives such 
a bill from the payee each month. In addition, positive action 
bill payment systems are cumbersome, costly, and inconve- 
nient because manual processes are usually required to pay 
each bill. Nor do most of these systems empower the payor 

15 to manage the time for or amount of payment of bills 
including the reversal of payments previously made. 
Negative Action Bill Payment 

In a single payee negative action bill payment 
arrangement, the payee usually gets authorization directly 

20 from the payor to automatically debit the payor's account at 
the payor's financial institution on a periodic basis (e.g., 
monthly) for the payee's fixed bill amount or possibly a 
variable bill amount. For example, some insurance compa- 
nies offer to automatically debit the payor's account at the 

25 payor's financial institution for the payor's monthly insur- 
ance premium payment. This automatic debit is usually 
accomplished through the Automated Clearing House 
(ACH) processes, or similar processes, which generally 
comprise a computer-based clearing and settlement opera- 

30 tion often operated by a Federal Reserve Bank, and whose 
purpose is the exchange of electronic transactions among 
participating entities. As seen in the above example, the 
payor's insurance premium is automatically paid each peri- 
ods and the payor takes negative action, or no action, to pay 

35 such a bill. However, these systems require the payee's 
financial institution to generate the electronic funds transfer 
(EFT) debit messages to initiate bill payment. The payor's 
financial institution receives the debit message via the ACH 
and verifies whether the payor's authorization is still active 

40 as well as whether the presented debit message conforms to 
the payor authorized parameters. This procedure is per- 
formed for each bill presented for each billing cycle. 

Additionally, these single payee negative action bill pay- 
ment arrangements are typically offered by the payee (or the 

45 payee's agent on behalf of the payee) to the payor directly, 
and therefore the payor deals with each individual payee in 
order to receive such service. Disputes or problems regard- 
ing payments are handled directly between the payor and 
each applicable payee. 

50 While this arrangement only requires payor action for the 
initial authorization to pay the payee debit messages, its 
acceptance in the industry has been unspectacular, as payors 
recognize that their control of the timing and amount of the 
payment is often forfeited in exchange for the need to 

55 respond to bills presented by each payee. For example, many 
of these systems have no flexibility regarding the payor's 
ability to determined when the bill is paid, and the payor is 
relegated to conforming to each individual payee system's 
predetermined dates and times for payment. Moreover, the 

60 payor has little or no control over each periodic payment, 
other than to completely terminate the bill payment service 
with the payee. In addition, other than to initially authorize 
a bill payment amount, the payor cannot change or alter the 
amount of the payments. In addition, there is usually no way 

65 for the payor to independently reverse a payment that has 
already been made without the cooperation and/or permis- 
sion of the payee. Due to the relatively low acceptance of 
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these systems, the fees generated by the number of partici- Consequently, while a variety of bill payment systems 

pants and the corresponding volume of message traffic in directed to positive/negative, single payee/multiple payee, 

such systems are also relatively low and the overall costs are and interactive systems and methods, have been provided in 

higher. An example of a common electronic funds transfer various forms to address shortcomings for general billing 
system is disclosed in U.S. Pat. No. 4,823,264, which issued 5 an( j bill payment procedures, these systems and methods 

to G. Deming on Apr. 18, 1989. have suffered from significant drawbacks of inconvenience, 

A modification of this negative action system is to have a m g n costs, lack of universal applicability and acceptance by 

third party provide the debit messages from multiple payees payors, lack of flexibility, and lack of control over payment 

to multiple payors. In this type of system, the payor usually amounts and payment timing by the payors. Many previ- 
authorizes the third party provider to automatically debit the 1Q QUsly ^ S y Ste ms are limited in that they recruire positive 

payor's account at the payor's financial institution on a act j on by the payor to implement payments, are available 

periodic basis (e.g., monthly) for a payee's fixed bill . for ^ types of bflls and debts 0 f predetermined 

amounts. The provider also establishes a recurring data file amounts require implementation of specialized equipment 

of fixed payment amounts along with a corresponding mdividuaI p rovidcrs D f services and/or goods, rely solely 

ffSSSKSI » ^^^^^^ 

accomplished through the Automated Clearing House timing or reversal of payment, or access to mfonnation 
(ACH) processes, or similar processes, as described above. regarding the current status of upconung or prevwus pay- 
Like the systems described above, the payor's bill is auto- 20 ments. 

matically paid each period and the payor takes negative Given such disadvantages of currently available bill pay- 
action, or no action, to pay such bill. However, such systems ment procedures and systems, there is a need for a payment 
still suffer the limitation that payors do not exert control over system that reduces the payor's time spent in paying bills, 
payment of the payee bills after the initial authorization and reduces the cost of paying bills, increases service, increases 
payees do not modify the recurring data file without the use 25 payor control over the bill payment process and standardizes 
of manual processes by the third party provider. the interface between the payor and multiple payees thus 
Financial industry acceptance of these fixed negative significantly reducing or eliminating the financial and opera- 
action systems has been unspectacular for many of the same tional interaction between a payor and each payee. In 
reasons cited above. These systems do not accommodate addition, there is a need for a system to eliminate the 
bills or debts that vary in amount fiom month to month 30 necessity for multiple payees to make delivery ol their 
based upon customer usage and the payees in such a system respective bills to consumer payors and to allow the possi- 
often have to be financial institution accounts (e.g., mort- bility of single delivery of bills from multiple payees to a 
gage loans, installment loans, leasing account, etc.) and may payor. 

also have to be at the financial institution which is the SUMMARY OF THE INVENTION 

provider of the payment arrangement, thus further limiting 35 . mo 

L convenience and applicabflity of these options. The limitations of previously known b,ll paying systems 

Similar to negative action bill [payment arrangements, a are overcome by a system constructed in ™^ ™* 

variety of other accounting and automated fund collection the princip es of the present invention. A b.U payment 

systemshavebeenavailableinvariousforms.suchasshown system havmg payor control that is constructed in accor- 

and denied in US. Pat. Nos. 5,222,018 (which issued to 40 dance with the principles of the ^72^ 

M Sharpe et al.) and 5,111,395 (which issued to R. Smith el storage for payee ^formation for each of a plurality of 

al) Th^M Sharpe et al. system for centralized processing payors, said payor information including cmld-payee infor- 

of account and payment functions is directed to a procedure mation identifying one of said payees authonzed to receive 

for determining an accounting for costs of shipping trans- a transfer of funds from one o said payors, a jecurnng 

actions. The system maintain! a database for participating 45 obligat on amount, and a re«irmg mmunum toeing 

shippers and carriers and debits and credits the shipper and interval; a b.U generator for generating at a foa ^predeter- 

carrier accounts in order to keep track of shipping services mined time a bill record from said W*^?^^ °" 

requested and delivered. Periodically, the system issues of said payees, said generated bill record including , an 

sutements of accounts receivable to the carriers and state- obligation amount and payment date so m at said generated 

meats of accounts payable to the shippers. Tbis accounting 50 bill record corresponds to a £j 

system thereby is directed to simplifying accounting for a one of said payors and said one of said payees * P»y said 

relatively large number of transactions which can be recurring obl.gat.on amoun on said payment date oorre- 

reported in periodic statements of accounts to be settled sponding to said muumum time interval said generated bull 

between the carriers and shippers. record being stored within said payor "-formation tor ^said 

The R. Sharpe et al. system allows the shippers to 55 one of said payors; and a TCF message ^r«tor fcr 

maintain furJlitb a predetermined trustee bank, so the generating a. a second predetermined 

central processing center of the system may issue instruc- corresponding to said generated b.U record to effect said 

lions to that bank to appropriately debit the shippers' transfer of funds. ... 

accounts and issue payment to carriers accordingly. The The system of the invention data receiving and processing 

actual payment is made in a traditional manner through the 60 equipment with any of a number of interactive systems and 

trustee bank, such as through electronic fund transfers and communication equipment to efficiently implement a bill 

the like While this system does provide for simplified processing and payment system which automatically tracks, 

accounting and account tracking procedures, it includes pays, and reports bills for a plurality of individual payees 

deficiencies similar to other systems described above in that without requiring action from the payors, yet provides each 

it lacks provisions for the shippers to control the timing of 65 payor significant control over payments and a mechanism to 

payments, modification of billing payment amounts, and/or fully or partially reverse payments made by the system 

reversal of payments after tbey are made. within an applicable provisional period. 
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In a further aspect of the present invention, the bill 
generator uses bill data received for one or payees, along 
with the payor information, and payee information to gen- 
erate the bills. The payee information and bill data prefer- 
ably includes provisional periods, bill amounts and due 5 
dates. The payor information for each payor preferably 
includes payor determined preferences for payment timing, 
maximum payment amount, and minimum interval for bill- 
ing and/or payment for each particular payee. 

The payor control interface responds to payor control 10 
messages to modify the timing, amount, and billing and/or 
payment interval for automatic payments of particular bills 
and to implement full or partial reversal of payments made 
within an applicable provisional period. Preferably interac- 
tive equipment is coupled to the payor control interface to ^ 
allow the payor electronic access from remote locations. The 
payor control interface further preferably includes a report 
generator which may include a printer or the like that 
formats data concerning payments made, payments due to 
the made, payments held or cancelled, payments reversed by 
the payor, and payor control preferences for each such 20 
payee. This formatted data is provided to payor through the 
payor control interface or through a hard copy device. 

The system of the present invention implements a method 
for generating bill records from payor information, payee 
information, and bill data received from payees and paying 25 
the obligations represented by the generated bill records at 
a predetermined time unless the payor transmits payor 
control messages that modify the generated bill and its 
corresponding payment. These modifications include chang- 
ing the date of payment, to place a hold on, cancel, or modify 30 
the payment of a particular bill, or to reverse a payment 
already made within the applicable provisional period. 

It is an object of the present invention to provide a 
negative multiple payee system which receives bill data ^ 
from multiple payees concerning one or more payors and 
initiates payment of variable bills for a payor at a predeter- 
mined time. 

It is an object of the present invention to provide a 
negative multiple payee system which receives payor con- ^ 
trol messages that include bill data from payors concerning 
multiple payees and/or bill data messages from multiple 
payees that include bill data for multiple payors and that 
initiate payment of fixed bills for a payor at a predetermined 
time. 4S 

It is an object of the present invention to provide a 
multiple payee system that reduces the need for the payor to 
directly communicate with the payee. 

It is an object of the present invention to provide a 
multiple payee system which permits a payor, once the payor 50 
information is initially established on the system, to autho- 
rize additional system payees for which the payor is already 
a customer through interactive means and without the need 
for additional payor sign-up. 

It is an object of the present invention to provide a 55 
multiple payee system wherein the interaction between a 
payor and the system is standardized for the payor relative 
to all payees. 

It is an object of the present invention to provide a 
multiple payee system which provides a payor more control 60 
over bill payment than currently available in other com- 
monly used payment systems and methods. 

It is an object of the present invention to provide a 
multiple payee system which empowers the payor with the 
ability to fully or partially reverse a payment that was 65 
previously made by the system within a provisional period 
applicable to a particular payee. 
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It is an object of the present invention to provide a 
multiple payee system which provides the payor with access 
to system information regarding payments made to payees, 
payments scheduled to be made to payees and other payor 
and payee information. 

These and other objectives met by the present invention 
may be discerned by reading the detailed description and 
reviewing the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

While the specification concludes with claims particularly 
pointing out and distinctly claiming the present invention, it 
is believed the same will be better understood from the 
following description taken in conjunction with the accom- 
panying drawings in which: 

FIG. 1 is a block diagram of a system for paying the bills 
of multiple payors to multiple payees in accordance with the 
principles of the present invention; 

FIG. 2A is a schematic diagram of a payor record that 
contains payor information for one of the payors coupled to 
the system of FIG. 1; 

FIG. 2B is a schematic diagram of a payee record that 
contains payee information for one of the payees coupled to 
the system of FIG. 1; 

FIG. 3 is a simplified schematic diagram of a preferred 
embodiment of the system for receiving and paying bills of 
payors shown in FIG. 1; 

FIGS. 4-6 illustrate a general overview of the operation 
of system and a preferred flow of transactions into and out 
of the system; 

FIG. 7 is a flowchart of the main menu for the preferred 
payment system shown in FIG. 3; 

FIGS. 8A-SL are flowcharts illustrating preferred payor 
activities for the system shown in FIG. 3; 

FIGS. 9A-9E are flowcharts illustrating a preferred set of 
payee activities for the system shown in FIG. 3; 

FIGS. 10A-10Q are flowcharts of payor child-transfer 
activities for the systems shown in FIG. 3; 

FIGS. U and 12A-12E are flowcharts depicting the 
preferred predefined batch-type processing procedures used 
in the system shown in FIG. 3; 

FIG. 13 is a flowchart illustrating a preferred process for 
handling payment and account items generated by the sys- 
tem shown in FIG. 3; 

FIGS. 14 and 15A-15C are flowcharts illustrating a 
preferred transaction reference file processing sequence for 
the system shown in FIG. 3; 

FIGS. 16A-16C are flowcharts depicting additional peri- 
odic scheduled processing for the system shown in FIG. 3; 

FIGS. 17, 18, and 19A-19K are flowcharts illustrating 
further detail and processing of various log record process- 
ing for the system shown in FIG. 3; 

FIG. 20 is a flowchart depicting further detail processing 
for EDI Forms to be originated to payees for the system 
shown in FIG. 3; 

FIG. 21 is a flowchart of the origination of, forwarding, 
and date control processing of items to be sent by the system 
shown in FIG. 3; 

FIG. 22 is a flowchart depicting the creation of payor 
child-transfer records on a periodic basis for a fixed amount 
for the system shown in FIG. 3; and 

FIGS. 23A-23B, 24A-24B and 25A-25B are flowcharts 
illustrating a preferred process for providing periodic sched- 
uled processing and reports for the system shown in FIG. 3. 
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For clarity and understanding, certain terms and phrases 
are used herein to describe the system structure and opera- 
tion of the method of the present invention. These terms and 
phrases are briefly defined as: 



5 Member Payee 



BankAccount 



BankAccountlD 



BankID 



Bill 



Bill Data 



Bank A financial institution, government agency, 

brokerage firm or other entity where a 
BankAccount is located. When Bank is 
prefixed with the word Operator, Payor or 
Payee, such term shall mean the Bank of the 
respective prefixed entity (eg. "Payor Bank", 
the Bank of the Payor). 
A checking, savings, credit card, brokerage, 
government benefits or any other account 
located at a Bank which can be debited or 
credited. When BankAccount is prefixed 
with the word Operator, Payor or Payee, 
such term shall mean the BankAccount of 
the respective prefixed entity (eg. "Payee 
BankAccount", the BankAccount of the Payee). 
The number or other information identifying 
a BankAccount. When BankAccountlD is 
prefixed with the word Operator, Payor or 
Payee, such term shall mean the 
BankAccountlD of the respective prefixed 
entity's BankAccount (eg. "Payor 
BankAccountlD", the BankAccountlD of the 
Payor BankAccount). 

The number or other information identifying 
a Bank. When BankID is prefixed with the 
word Operator, Payor or Payee, such term 
shall mean the BankID of the respective 
prefixed entity's Bank (e.g. "Operator 
BankID", the BankID of the OperatorBank). 
A Standard Bill, Contract Bill, Vbluntary 
Obligation and/or Other Obligation. 
Information received from the Payee, 
information received from the Payor or 
information otherwise established on the 
inventive system which contains certain 
fundamental components of a Bill such as an 
amount and due date. 
A record related to a Payor Record 
identifying a valid Payee for such Payor. 
The number or other unique identifier (i) 
assigned by the Payee and which identifies 
a Payor to a Payee; or (ii) assigned by the 
inventive system for its own purposes and 
which associates a Payor to a Payee. 
A Log Record containing Payor Child- 
Transfer information or Payee Child-Transfer 
information. 

An oral or written agreement or 
understanding under which a payment 
amount or series of payment amounts are due. 
A customer service representative of the 
Operator. 

The exchange, between Persons, of 
computer proccs sable data in a standard 
format. Standards activities undertaken by 
the Accredited Standards Committee (ASC) 
X.12 Electronic Data Interchange within the 
American National Standards Institute (ANSI) 
encompass any subject area for which EDI 
standards can be developed. 
The data that is exchanged in order to 
convey meaning between Persons engaged 
in EDI, consisting of a specific group of 
segments, or records, within a transaction 
set that represents a business document 
(e.g. invoices, purchase orders, inventory 
inquiries, bills of lading, payments, and 
others between suppliers and customers). 
A file containing Log Records. 
A record that contains information relating to 
a specific transaction or process in the 



Child-Payee 
Child-PayeelD 



Child-Transfer 
Log Record 

Contract Bill 



CSR 



EDI 



EDI Form 
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inventive system which is used to 
communicate between different components 
of the inventive system. 
A Payee that has entered into an agreement 
with the Operator whereby such Payee has 
certain obligations and agrees to follow 
certain rules and requirements relative to the 
inventive system. 

A minimum acceptable time period in which 
the inventive system accepts successive 
payments to, and/or Bills or Bill Data from, a 
particular Payee or Payor. 
Multiple Payee System A Bill payment system or arrangement where 



Minimum Interval 



or Multiple Payee the Payor enters into an agreement with a 
Person that offers to act as an agent of the 
Payor and grant certain rights to such Payor 
15 whereby Payors can make payment to such 

Person and such Person independently 
makes payment to two or more Payees that 
are not directly or indirectly under common 
control or ownership. Multiple Payee 
Systems are viewed from the perspective of 
20 ihe payor. 

Negative The concept associated with Payors that one 

or more events automatically happen (e.g. 
payment of Bills are automatically initiated) 
unless the Payor takes action to stop such 
event or events from happening. 
25 NonMember Payee A Payee that is not a Member Payee. 

Operator The Person or Persons that own and operate 

the inventive system and which is the 
initiator of all monetary transfers of funds. 
Other Obligation Any situation, commitment or arrangement 

under which a payment amount or series of 
3Q payment amounts are expected to be paid. 

Payee A Person that is the intended original end 

recipient of a monetary transfer of funds 
from a Payor. Any derivative from such 
monetary transfer of funds (e.g., reversal, 
return, re-try, adjustment, etc.) does not 
change the status of the Person as a Payor 
or Payee. When the term "Payee" alone is 
used it refers to both Member Payees and 
NonMember Payees. 
Payee Child-Activity A record related to the Payee Record which 
contains Operator fee information used to 
generate Payee Child-Transfer record(s) for 
purposes of assessing Operator fees to a Payee. 
Payee Child-Transfer A record related to a Payee Record which 
contains information used to initiate a 
monetary transfer of funds between a Payee 
and the Operator. 

Payee File or Database The file or database containing Payee Records. 



35 



40 



45 Payee Information 

Payee Record 
PayeelD 



50 



Payor 



55 



Log Ffle 
Log Record 



Information provided by or on behalf of a 
Payee such as the Payee name, address, 
Payee BankID and Payee BankAccountlD. 
Record or records containing Payee 
Information for a particular Payee. 
The number or other unique identifier 
assigned by the inventive system to identify 
the Payee 

A Person that authorizes the Operator to 
originate monetary transfers of funds to a 
Payee Any derivative from such monetary 
transfer of funds (eg., reversal, return, re- 
try, adjustment, etc.) does not change the 
status of the Person as a Payor or Payee. 
A record related to the Payor Record which 
contains Operator fee information used to 
generate Payor Child-Transfer record (s) for 
purposes of assessing Operator fees to a Payor. 
A record related to a Payor Record which 
contains information used to initiate a 
monetary transfer of funds between or 
among a Payor, Payee and/or the Operator. 
Payor File or Database The file or database containing Payor Records. 
Payor Information Information provided by or on behalf of a 
Payor such as the Payor name, address, 
Payor BankID and Payor BankAccountlD. 



Payor Child-Activity 



60 Payor Onld-Transfcr 



65 
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Payor Record Record or records containing Payor 

Information for a particular Payor. 

PayorlD The number or other unique identifier 

assigned by the inventive system to identify 
the Payor. 

person An individual, partnership, joint venture, 

corporation or other legal entity. 

PIN The personal identification number 

associated with a Payor. 

Positive The concept associated with Payors that no 

payment occurs (e.g. Payment of bills are 
not automatically initiated) unless the Payor 
takes action to initiate such current or future 
payment 

Prc-Note Information sent to a Bank, Payor or Payee 

requesting verification of information. 
Provisional or The time period during which a Payor may 

Provisional Period fully or partially reverse a Payor monetary 
transfer of funds. 

Single Payee System A Bill payment system or arrangement which 
is not a Multiple Payee System. 

Standard Bill A standard invoice or bill, which may include 

a written paper document or an electronic 
data document, an account summary, or any 
other description of or notice of a payment 
amount due. 

TCF A Transfer Communication Facilitor such as 

a facility, system and/or arrangement used 
to settle monetary transfers of funds and/or 
communicate information between and 
among Payors, Payees and the Operator and 
their respective Banks and BankAccounts. 
For example, one such TCF that the Operator 
may use is the Federal Reserve Bank 
Automated Clearing House (ACH) System. 

TCFInterfaceBank A Bank that the Operator may use to 
interface with a TCF. 

Transaction Reference A file containing Transaction Reference 

File Records. 

Transaction Reference An audit record used to retain and store 
Record information about each record sent out by 

the inventive system for which historical 
tracking, balancing and/or research is 
desired. For example, Payor Child-Transfer 
records, Payee Child-Transfer records and 
Prc-Notes sent out of the inventive system 
would have corresponding Transaction 
Reference Records. 
Vbhintary Obligation A situation, commitment or arrangement 

under which a voluntary payment amount or 
series of voluntary payment amounts are 
expected to be paid- For example, Vbluntary 
Obligation could include charitable donations, 
church donations, donations to a not for 
profit organization, or other voluntary payments. 
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Also, as used herein, "daily" will generally mean a 
"business" day. Other terms will be identified below in the 
detailed description, as appropriate. 

A block diagram of the system constructed in accordance 
with the principles of the present invention is shown in FIG. 
1. The system 10 includes a bill generator 12 that is coupled 
through a payor control interface 14 to a first plurality of 
Payors, P A , . . . P„. A communication interfaee 16 couples 
bill generator 12 to a second plurality of payees Pe A . . . Pe„,. 
The bill generator 12 is also coupled to storage for Payor 
information 18 (Payor Database) and storage for Payee 
Information 20 (Payee Database). The Payor Information 
stored in the Payor Database 18 is initially entered by an 
Operator for system 10 through known devices such as 
keyboard entry or scanning equipment. In a similar manner, 
the Payee Information is entered into the Payee Database 20. 

In its simplest form, bill generator 12 may use the Payee^ I 
Information within the Payee Database 20 as a recurring" 
riatafi le to search the Pavor Inform ation in ihe Pavor Data- 
base"18to generate bill records at predetermined tij 



12 



to^j^ub, Hail y - t1 -- 1ir r j i ii 1— i - — ^ j - 

Paypror P flYnr7Tnft> rimitf i r>n i gl ' CD as a number of days poor 
to a duejlaj£. These bill recorOSTnay oe stored elsewhere in 



iiiT^temfor later processing or they may be associated 
with Payor Information corresponding to particular Payors 
within the Payor Database 18. On some type of recurring 
basis, either periodically or at operator initiative, bill gen : 
era tor 12 processes generated bill records and trapsjgrs them 
hoTTCF message generator 22. Using the generated bill 
records, the TCF message generator 22 generates, at prede-^ 
grrnl ne^TimesT E lectronic Funds Transfer (Eh i) messages 
ihlTTfehit Pa ynr'BarikAcco u ntS through f^me type of TCF 
transfer systernTThe generated bill records are updated to 
indicate a transfer has occurred and the records are placed in 
the Payor Database 18. Each of the transmitted debit mes- 
sages that correspond to a particular Payee are accumulated 
and are used to generate a settlement message. A settlement 
message is transmitted through the TCF system to provide ^ 
an overall credit/debit to the Payee Bank. 

The payor control interface 14 receives payor control 
messages from the Payors coupled to the system 10. These 
payor control messages are used to modify data within the 
generated bill records. This capability of modifying the 
generated bill records includes the ability to modify gener- 
ated bill records that indicate a transfer of funds has 
occurred. Bill generator 12 and TCF message generator 22 
process such modified generated bill records to reverse, 
either fully or partially, the transfer of funds. 

The system 10 as shown in FIG. 1 may be further 
expanded so that the communication interface 16 receives 
bill data messages from the Payees. These bill data messages 
include a PayeelD, a Child PayeelD, an obligation amount, 
and an obligation due date. This information is used by the 
bill generator 12 along with Payee Information from data- 
base 20 the Payor Information from database 18 to generate 
bill records. The bill records generated by using bill data 
messages may have variable obligation amounts or due dates 
based upon customer (payor) usage or the like of a payee's 
services or goods. 
40<\ An exemplary data record structure for the Payor Infor- 
mation for one of the Payors stored within database 18 is 
shown in FIG. 2A. The Payor Information includes a Payor 
Record 30, a Payor source account record 32, a Child- Payee 
Record 34, and a bill record 36. The Payor Record 30 
45 includes a number of data fields. These data fields include 
storage for a PayorlD, Payor name, Payor^ addisss^ayor 
rec gdstTtus. P I ff. first Pavor source account re cord pointer, 
firsTPayor Child-Payee record pointer, and first Payor bill 
record pointer. These records and data fields that comprise a 
so Payor Record are presented by way of example only. Jhe 
Payorl D is a_ number used to provide an effi cient numerical, 
sch eme for identifying payor records. The Payor name and 
address fields are provided for identifying the Payor in 
reports or interactive menus as explained below. The Payor 
55 record status is used to indicate the status of a Payor within 
the system and confirm whether an obligation submitted by 
a payee may be paid or not. The Payor status may be one o£ 
th e values: Active, Temporarily ^rjended^ PejTOangntly, 
Suspended, Closed, p r jDejeied .. The first Payor source 
60 account record pointer indicates the location of the first 
source account record that identifies a Payor BankAccount 
from which funds may be transferred. The first Child-Payee 
record pointer indicates the location of the first Child-Payee 
record for the Payor and the first bill record pointer indicates 
65 the location of the first bill record for a Payor. 

An exemplary Payor source account record 32 associated 
with a Payor Record is shown in FIG. 2A. That record 
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prrviRRgi no anH fg raflircfi The Payee type indicates the type 
oTService provided to trie Payee by system 10. The status 
field is used as discussed above for the other records shown 
in FIG. 2 A. The PayorBank and BankAccountlDs identify 
the Payor's bank and account to which the settlement 
messages are transmitted. The Provisiona lJPeriodtype and 
length define whether the Provisional Period maytommence 
after payment date, after payment date up to due date, or 
after the due date, for example. The minimum tim<Mnj£fy^l 
is preferably a default value set by the Operator of system 10 
that defines the minimum billing cycle for j. Payee . This 
value is used by system 10 to set the minimum time interval 
field in the Child-Payee Record 34. However, the minimum 
time interval data field in the Child-Payee Record may be 
modified by a Payor. Thus, the Child-Payee Record, and not 
the Payee Record, is used to generate bill records. 
a The illustration of FIG. 3 shows a simplified schematic 1 
* 'block diagram of a presently preferred exemplary embodi- 
ment of a Provisional, Multiple Payee, Negative payment 
20 system 100 set up in accordance with the principles of the 
present invention. Particularly, FIG. 3 shows a preferred 
combination of structure and apparatus for implementing the 
present invention in a relatively large scale commercial 
arrangement, wherein a system 100 is implemented for 
automatic Bill tracking and payment. It is contemplated that 
the Operator of system 100 establishes, through appropriate 
contractural agreements or the like, an understanding with 
various Payors that Bills from designated Payees are at 
pTgffete. rr ryned time s such aj periodically (e.g. on a monthly 
30 basis) paid according to Bill Data submitted by Payees 
relating to Payors or at predetermined times such as peri- 
odically paid according to Bill Data established on system 
100 based on instructions from Payors relating to Payees. 
These contractural arrangements clarify the Operator's obli- 
35 gations for receivi ng and ^sjflfjfig Payor information and 
Pa yee information and tor mutating payment ot Bills for 
eacB Payor to the Payees at predetermined times in accor- 
dance with a predetermined set of provisions for handling 
STor from a payee to a pavor to r everse a transfer. ! Bill Data and other data from both Payors and Payees. 
-fhT* bill record includes "the ^avor^D, Pa^^p", \4*X Particularly, once a Payor Record and related Child-Payee 
P ^nrAccounL a status field, due data, payment type, pre- \ ^ record is established with information from a Payor and a 



includes an account code, status field, Payor BankID, Payor 
Account ID, and a Payor source account record pointer. The 
account code identifies the type of the source account. For 
example, it could identify the account as a checking account. 
The status field is the same as explained above. The Payor 
BankID and Payor BankAccountlD identifies a financial 
institution and an account at that institution from which 
funds may be transferred to satisfy obligations. The Payor 
source account record pointer indicates the location of the 
next Payor source account record, if there is one. 

As shown in FIG. 2 A, the first Child -Payee record 34*" 
associated with the Payor Record also includes a number of 
data fields. The C hild-Payee record is used to ffin t ifr 
Pay ees that maCTT"or nave peen auihodze^ to receive 
payment of an obligation from the associated Payor . The 
Child-Payee record includes data fields for PayeelD, Payor_!s 
a ccount number with the Payee T payment type, maximum 
am ount authorized fo r_ao obligation payment to the Payee, 
the status of the Payee which may have the same values as 
the status field for the Payor Records, a minimum time 
interval, a default source account ID, and a second child 
payee pointer. Again, the PayeelD is a numerical scheme for 
ide ntify ing each of the pace's withi n the inventive system: 
Tb e~ maximum amount data field is used tr> iflfiflflfv 'he 

mQvIrmim ammint nf an nh ligation aulhori^d bv the payor 

for payment. The minimum payment interval defines a 
billing cycle length, and the default source account ID 
defines the Payor BankAccount from which funds are trans- 
ferred to pay the Payee. The second child payee pointer 
indicates the location of the next Child-Payee record asso- 
ciated with the Payor Record. If there is no other payment 
record, a terminating value is inserted in the field. Again, the 
data record structure of the Child-Payee record shown in 
FIG. 2A is by way of example only. 

The first bill record pointer shown in flG. 2 points to a bill 
record 36. Thes e bill records are pejierated and later p ro- 
cessed to g eneratetne Jbhi' messages ior implementing; a 
trattSter^ot hinds Irom a payor to a payee to_j5atisfe^anj 

transfr 
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sentment^feTPayment amount, Payor source account, and 
a next bill record pointer. The PayorlD and PayeelD are the 
same as discussed above. The Pav or aqcount id e ntifie&jfoe 
Payor's, ?gc nnni with the Paye£ ~The due date and present- 
ment dates refer to the date the payee has identified for 
payment and the date the payor has designated for fund 
transfer, respectively. The payment type indicates whether 
payment is to be made l electronicaii,y ^ r not and t\te Payor 



source account identifies the account from which funds are 



transferced.for-pAymefltJhe payment amount is the dollar 
amount to be indicated in the debit message to satisfy an 
obligation. A status field is provided to further control 
whether an obligation is paid during processing of the bill 

record. The status field for the bill record may include one J55 a Payor Child-Transfer Record from "Ready" to "Hold 
of the following status values: Ready, Hold, Paid, Returned, 
or Cancelled. The use of the status field and the processing 
of the bill records are described in more detail below. The 
data structure of the bill record shown in FIG. 2A is 
exemplary only. 

FIG. 2B shows an exemplary data record in database 20 
that contains Payee Information for one of the payees. This 
record 40 i ncludes PayeelD, status field, Payee type. Payee, 
namelnd a ddress. Fa vor BankID and Pavju , 



Bank Accoun tlDj pay ment method, P rovisi onal Period type w 65 
Provisional Peri6d length, and minimum time interval. The 
PayeelD, name and address identify the Payee for record 



Payee, Bill Data may be collected from Payees in an 
ongoing manner. Additionally, Bill Data and other informa- 
tion affecting the payment of Bills may be provided by payor 
is control messages from Payors. The'bill records, also called 
Payor Child-Transfer Records, are periodically sorted for 
processing and payment on pr e jei gpnined^l^s determin ed 
b y individual Payors relative to du ed a ^ esfor thos g.particular 
Bills. Payor Child-Transfer Record processing is undertaken 
automatically at p redetermined times such as peri odic (e.g. 
daily) intervals for each Payor, ana ail bill records deter- 
mined to be ready for payment at that time may beselgged 
fo r payment processing unless the Payor takes po sitive 
action (a) to control such payment by changing the status of 

or 

Cancelled", (b) to modify the amount to be paid or (c) to 
change the date for initialing a payment. After a payment is 
initiated by the system 100, the Payor may implement a 
reversal through a payor control message during the appli- 
60 cable Provisional Period. As discussed below, the Provi- 
sional Periods for payment reversals are preferably estab- 
lished by the Operator for all Member Payees or, 
alternatively by contract with the individual Member 
Payees, and maintained in the Payee Records of the system. * 

The preferred embodiment of the inventive system 100 
shown in FIG. 3 includes a central computer system 110, a 
plurality of remote digital personal computers 112, prefer- 
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ably running associated a synchronous communication soft- audio prompts, an analog-to-digital converter and audio 
ware to operate compatible modulator/demodulator devices editing software is required (e.g., the Bit Works Audio 
(e.g. modems) which translate analog signals to/from the Station including the Bit Works Audio Works Board from 
remote digital personal computers when necessary, a public Bit Works, Inc., Thomhill, Ontario, Canada) which accepts 
digital data network ("PDN") 114, packet assembler/ 5 a microphone (such as an Audio Technica model 150D) as 
disassembler, access concentrator multiplexers (sometimes analog input for a person to record the needed prompts. In 
these assemblers, disassemblers, multiplexers and related addition, the Audio Works Board allows the developer to 
equipment are generally referenced as u communications listen to the digitized prompts by using headphones. Effi- 
interface assistors" 116), and a protocol translator front-end cient and effective interactive audio menus may then be 
processor (e.g. FEP) 118. In addition, the system 100 1Q written using a standard approach (e.g., see "PC-Based 
preferably includes a plurality of voice telephone devices Voice Processing" by Bob Edgar, and published by Telecom 
(e.g. 120), and one or more digital personal computers 122 Library, Inc., ISBN No. 0-936648-36-8 showing a method- 
running an operating system such as the MS-DOS Operating ology that may be used). 

System software, in turn running a graphical user interface Once the IVR has been designed, and the prompts digi- 
program such as the Microsoft Windows (e.g. version 3.1 15 tized and edited, the *C programs may be developed around 
software). the IVR system design. Within the *C language there are 
In a preferred example, the interface program running on header files that are used to define global variables that are 
digital personal computer 122 controls an IBM 3270 SDLC used within the program. Additional *C header files may be 
terminal emulator, such as the Rumba for the Mainframe obtained, for example, from Voice Information Systems, 
version 3.2 software (as available from WallData 20 Inc., and preferably features the TI/F Dynamic Link Library, 
Corporation, Redmond, Wash.) under a high-level language DLL, to define the functions and their respective parameters 
application programming interface (e.g. HLLAPI) on a and return values used within the DLL that are used to 
SDLC communications adapter such as the WallData SDLC communicate with the Dialogic Voice Board driver software 
(co-processor board, running a DOS protected mode inter- running on the IVR personal computer as a "terminate and 
face gateway (such as the TI/F DLL from Voice Information 2S stay resident", TSR program. The DLL uses the DOS 
Systems, Inc., Bryn Mawr, Pa.) using voice processing Protected Mode Interface specification to allow software in 
boards with analog telephone interfaces, dual-tone multi- a Windows-based environment to communicate with DOS- 
frequency digit (e.g. DTMF) or multi-frequency digit (e.g. based driver software. In the normal DOS environment, IVR 
MF) detection and generation, and call progress analysis systems can be developed by using state-machine software 
such as the Dialog 41D Voice Boards from Dialogic Cor- 30 to process each event that is generated from the Dialogic 
poration (Parsippany, NJ.). The digital personal computer voice board and standard approaches as mentioned above. 
122 preferably runs an interactive voice response ("IVR") i D the preferred embodiment, the software is developed in 
system software to perform tasks such as shown in FIG. 7 for a Windows event-based environment. Since the DOS envi- 
Payors needing touchtone telephone access to the on-line ronment does not generally have the ability to efficiendy 
Payor Database 18, and accessing the central computer 15 35 handle multiple processes, the state-machine concept is 
through a front-end processor (e.g. 130) such as an IBM necessary for the IVR software to handle each individual 
Model 3745 Front-End Communications Processor. event for the multiple lines as they are received from the 

The IVR system defined by computer 122 and its asso- Dialogic Voice Board. The preferred embodiment includes a 

ciated software and peripherals may be adapted for partial- separate program for each voice channel, and a separate 

lar applications to provide appropriate user/system interac- 40 module for each audio menu, data entry prompt, and "help" 

tion and control. There are no known "off-the-shelf* IVR prompt within each program. This modularity gives the IVR 

system software packages available that provide all of the system for each channel the ability to make "decisions" 

preferred audio menu, data entry mechanism, and system based upon the events that are received from the Dialogic 

transactions. A person of ordinary skill in programming Voice Board. Each possible event anticipated from the voice 

digital personal computers, however, can develop this IVR 45 board is defined and programmed in a single event module, 

software by using the C/C++ language in an integrated which in turn passes the event to the appropriate module by 

program development environment (e.g., the Borland C++ using variables that are modified dynamically during the 

version 4.0 from Borland International, Inc., Scotts Valley, course of an IVR conversation (i.e., developed for each 

Calif.), using Windows version 3.1 Application Program- audio menu, data entry prompt, and "help" prompt). The 

ming Interface functions. 50 various different types of events are defined by Dialogic 

For example, the software may be developed on a digital Corporation in the Technical Manuals provided by Dialogic 
personal computer (e.g., an Intel 80486 with at least 4 MB Corporation that accompany each D41 Voice Board, includ- 
of RAM 130 MB hard disk space; using at least a mono- ing "On-Hook", "Off-Hook", "DTMFTerminator 
chrome VGA monitor, and a personal computer keyboard). Received", "DTMF Maximum Digits Received", "End of 
In the preferred embodiment, the software is written in 55 Playback", "Time-Out", "Silence", and "Dial Complete". 
ASCII-text source code, compiled into Intel-specific object The IVR system in the preferred embodiment communi- 
code in the program development environment, and the cates with the on-line central computer 110 through front- 
object code is linked with the necessary libraries (such as the end processor 130 to access Payor Information maintained 
Windows Software Developers Kit) into Intel processor in Payor Database 18. In setting up the IVR system, the 
executable programs. 60 developer determines when the IVR system needs to com- 

The audio prompts for menus, data entry prompting, and municate with the on-line central computer, and what infor- 

"help" information are preferably created in a digital format mation the IVR system needs at various points in the 

such as a 16-bit linear 8,000 sample-per-second Pulse Code conversation with the caller. The on-line central computer 

Modulation, PCM, format, that is converted to a 4-bit 6,000 110 has a set of pre-defined transactions that can be accessed 
sample-per-second Adaptive Differential Pulse Code Modu- 65 by the IVR system, and returns information in a pre-defined 

lation (ADPCM) format for use with voice response boards format to the terminal emulator of computer 122. In order 

(e.g., Dialogic model D41-4-port). In order to create these for the IVR system to communicate with the on-line central 
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computer, a High-Level-Language Application Program- Ohio using X.25, TCP/IP, IBM 3270 SDLC terminal emu- 

ming Interface, HLLAPI, function library that is specific to lation; and/or by sending a written request through the mail 

the terminal emulator can be provided to facilitate commu- (e.g. United States Postal Service, or other equivalent 

nication between the IVR system and the terminal emulator. service) to the CSRs of the Operator using a customer 

In an exemplary embodiment, the HLLAPI function library 5 service terminal 132. 

for the terminal emulator may be the Rumba Tools for In the preferred embodiment, PDN 114, communications 
EHLLAPI (Extended High-Level Language Application interface assislors 116, and dial-up telephones 120 are 
Programming Interface) version 1.1 from WallData entirely conventional and arc preferably operated and main- 
Corporation, Redmond, Wash. The function library includes tained by a local or regional telephone capable of perform- 
a dynamic link library (DLL) that is accessed by the func- 10 ing these tasks. PDN 114 may comprise, for example, a 
tions denned in the 4 C header files, also provided by the conventional PDN which communicates data packets in 
library manufacturer. Within the IVR system, the software CCITT X.25 protocol (as defined in Malaga-Torremolinos in 
preferably includes a communication module for enabling 1984, and Melbourne in 1988) between a computer 110 and 
communication with the on-line central computer. Param- a packet assembler/disassembler; and the asynchronous 
eters are passed to the communication module in order for 15 communications interface may comprise conventional tele- 
it to perform the proper transaction and return the response phone company operated subsystems which convert X.25 
back to the calling module. packet protocol existing on the PDN 114 into conventional 

While the specific details of equipment and software asynchronous data format (e.g. with seven or eight data bits, 

packages are included for completeness of this example, it a start bit, a stop bit and conventional error checking fields), 

should be clear that other combinations of structures and 2 o Preferably, system 100 performs asynchronous data com- 

software could equally be provided by one skilled in the art. munications through PDN 114 within a protocol translator 

In addition, the system preferably includes a plurality of 118 and a digital personal computer interface processor 152, 

customer service terminals 132, which are preferably digital which initiates and answers dial-up telephone communica- 

personal computers, attached to a local area network running tions with remote digital personal computers 112 and data 

IBM 3270 SNA terminal emulation software (such as 25 terminal equipment 140. Thus, remote digital personal com- 

DynaComm/Elite version 3.4 from NetSoft, Inc., Laguna puters 112 may interface with system 100 using standard 

Hills, Calif.), and accessing the central computer 110 asynchronous protocol, while a Member Payee data terminal 

through a separate digital personal computer running gate- equipment 140 may interface with system 100 using a 

way software 134 (such as AdaptSNA LAN Gateway to the protocol that is standard and conventional for whatever 

Host version 4.3 from NetSoft). As will be understood, this 30 particular type of data terminal equipment is being used by 

operator administrative access may be similarly provided via the Member Payee. In a preferred example, central computer 

any terminal or device capable of communicating with a 100 may interface with the digital personal computers 112 

central computer 110 (e. g. using IBM 3270 bi-synchronous using standard 3270 Physical Unit 2.0 and Logical Unit 

SNA protocol). Customer service terminals 132 may be Type 0 protocol, with conversions between the two protocols 

placed in various locations to assist Operator employees in 35 (as well as distribution of the signals generated by the central 

entry of Payor Information and Payee Information, and/or to computer to specific remote digital personal computers) 

assist Payors and Member Payees in directly interfacing accomplished with a protocol converter front-end computer 

with the system, as described below. (which may include hardware and software to accomplish 

The system 100 is further illustrated as including a the requirements of both protocol translator 118 and per- 
plurality of data terminal equipment devices (e.g. 140) 40 so™ 1 computer interface 152 in a single device) such as a 
capable of creating, transmitting, receiving, interpreting, and Stratus Model R25 available from Stratus Computer Inc. of 
processing data files between Payees and the system 100 Detroit, Mich, which may communicate with conventional 
over PDN 114 using stand ard communications protocols PDN 114 equipment that may also handle protocol conver- 
such^sasvn^n ousX^rlC ,'^ ^<P/|P ^umnim sion and the packet assembler/disassembler and communi- 
R emote Job 1511?^ or IBM 3275 polled bi-synchronous 45 cations interface provided by the telephone company, 
terminal emulation. Exemplary data terminal equipment 140 Many of the customer service terminals 132 in the pre- 
might include personal computers, mini computers, main ferred embodiment are digital personal computers that 
frame computers, a magnetic tape device, and ojfr er e q uip- access the central computer 110 via IEEE 802.3 standard 
rflent which may bemused to perform these ^cWns. Data ethernet lObaseT physical connectivity in a local area net- 
may be similarly communicated between a Member Payee, 50 work using IPX/SPX protocol through a digital personal 
or its representative, and the central computer 110 via data computer running gateway software 134 between the local 
terminal equipment through the PDN 114, the packet area network and a token ring network into the front-end 
assembler/disassembler, the communications interface, or communications processor 130, such as the IBM 3745 
via dial-up telephone lines or leased lines as described Front-End Processor, and then into the central computer 110. 
above. 5i^r> Central computer 110 is also shown as electronically 

Data may be communicated between a Payor and the ^ communicating with additional remote data processing sys- 
central computer 110 in several ways, including via a remote terns at a TCF, a TCFInterfaceBank and a Payee. It is also 
digital personal computer 112 through the PDN 114, com- contemplated that central computer U0 may electronically 
munications interface assistors 116, and dial-up telephone communicate with other remote data processing systems 
lines 144; via a touch-tone telephone device 120 through the 60 such as those at a Bank and/or third party information or 
PDN 114 directly to an IVR system; via a remote digital service provider. Such electronic communications may be 
personal computer 112 through a leased line 148; via an over dial-up telephone lines, leased telephone lines, or other 
analog voice telephone device 120 through the PDN 114 to special communications arrangements/protocols (e.g., mag- 
establish a person-to-person conversation with a CSR netic tape transfer or the like). The electronic communica- 
employed by the Operator and using a customer service 65 tions between the central computer 110 and a TCF, a 
terminal 132; via a plurality of automated teller machines TCFInterfaceBank and a Bank pe rmit monetary and non- 
such as the NCR 5085 from NCR Corporation, Dayton, monetary information to be sent and received. The electronic 
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communications between a Payee, a Payee's agent, or other example, the Payor Child-Transfer activities and the Payee 

third party information or service provider allows central activity choices are generally available for interactive input 

computer 110 to communicate payment-related data, non- only by CSRs, who can access all Payor, Payee and Payor 

payment related data, statements, and reports, as discussed Child-Transfer activities. While a Payor may initiate the 

b e i ow . 5 addition of a Child-Payee to its Payor Record, the actual 

Turning now to the other drawing figures which illustrate input of the Child-Payee record is preferably undertaken, or 

various combinations of structures, procedures, and detailed at least checked and approved, by a CSR to ensure proper 

logic for an exemplary embodiment of the present invention, completion. 

FIGS. 4-6 illustrate a general overview of the operation of Following FIG. 7, the interactive response portion of the 

system 100, and a preferred flow of transactions into and out 1° present invention enables CSRs to access system 100 as 

of the system when employed in the manner contemplated desired to add a new Payee and related Payee information 

herein. Particularly, FIG. 4 depicts various unscheduled (e.g., add a new Payee Record to system 100). Payee 

processing tasks undertaken by the system which occur on Information provided to system 100 includes the Payee 

a predetermined basis such as on a periodic (e.g. daily) basis. name, address, Payee BankAccountID, Payee BankID, 

^ Payors have the ability to add, modify, or delete Child- 15 default maximum payment amount, payment type (e.g. 

^T gEg^^ that ^-ntrnTTh^nT^. Negative or PosiUve) default Minimum Interval, Provi- 

ing^paymcnls for that particular Payor through system slonal Penod > and lhe hke * 

100. Because the Payor may initiate the addition of a Add a New Payor Record 

Child-Payee, deletion of a Child-Payee, or modification of Where an interactive transaction includes Payor activities, 1 - 

information regarding an existing Child-Payee Record or 20 Selection of that menu function results in an appropriate 

payment parameters for any of its Child-Payee Records, it is device dependent display, as shown in FIGS. 8A-8L, respec- 

preferred that system 100 be constructed with the ability to tively. As an example, if a Payor accessed system 100 via a 

properly receive such input as an unscheduled event. digital personal computer 112, a screen menu provides a 

As mentioned above with respect to FIG. 3, system 100 „ subset of the options shown in FIG. 7. FIG. 8A shows a 

has a payor control interface that preferably includes the Payor activity which can only be completed, in the preferred 

protocol translator 118, and personal computer interface embodiment, by a CSR of the Operator, and so this option 

processor 152, the IVR 122, the fronted communications does not show as an option to a Payor. If the CSR correctly 

processor 130, the central computer 110 and various on-line enters all of the applicable Payor Information when adding 

files (e.g. 160), to receive, translate, and store Payor infer- a new Payor, a new Payor Record is added with a status field 

mation as appropriate. It is preferred that the payor control value of Temporarily Suspended and the Payor is assigned 

interface for receiving such information further includes a PayorlD. This Payor Record is preferably stored in the 

interactive devices which provide Payors with convenient on-line files 160, in a sub-file designated as the Payor File 

access to the system 100 from remote locations. Particularly, or Database 18. In addition, a Log Record relating to the new 

FIG. 3 illustrates examples of such interactive devices, „ Payor Record is placed in the Log File storage of on-line 

including digital personal computers 112, telephone devices files 160. As explained in more detail below, the status field 

120, ATM machines 150, or person-to-person conversations value of Temporarily Suspended may be used during the 

with (or mail delivery of instructions to) a CSR who can initial start-up period while validation of the Payor BankID, 

input such information via the customer service terminals Payor BankAccountID, and other Payor Information is 



132. Payor Information is preferably processed into system ^ be ing completed . 
100 via one of the pre-defined interactive procedures illus- Change an Existing Payor Record 
trated in FIGS. 7, 8A-8L, or 10A-10I. An existing Payor Record may be changed in accordance 

As an example, a Payor may utilize the payment control with the flow logic of FIG. 8B, wherein the PayorlD is 
apparatus of system 100 via an interactive device such as a entered so that the Payor Record may be accessed from the 
digital personal computer 112 through PDN 114 and the 4S on-line files 160 (i.e. from the Payor File). As mentioned 
computer interface 118, 152 illustrated in FIG. 3, whereupon above, this is an activity which is preferably directly acces- 
a menu driven interactive procedure enables the Payor to sible by a Payor, through the interactive devices and Payor 
input any of a variety of Payor Control messages. FIG. 7 control messages described herein. As noted m FIG. 8B, if 
illustrates the architecture for a preferred interactive the Payor Bank information (e.g., Payor BankAccountID or 
response system of the present invention, wherein a main 50 Payor BankID) is changed, the status field of the Payor 
menu is provided for use by the Payor. As shown in FIG. 7, Record is set to the value of Temporarily Suspended to 
the menu is "device dependent", meaning that a menu is enable verification of the new information. A Log Record is 
provided to the Payor in an appropriate and convenient also prepared and stored in the on-line Log File as shown in 
format, and only activities which may be accessed by Payors FIG. 3. - 
are allowed. For example, with an interactive device such as 55 Set Payor Record to Temporarily Suspended/Active 
a digital personal computer 112, the menu is displayed on FIG. 8C illustrates the preferred interaction of procedures 
the monitor, prompting the Payor to select a menu function and equipment for setting an existing Payor Record status 
or to directly enter one of the transactions displayed, while field to Temporarily Suspended. FIG. 8D shows the similar 
communication via telephone lines would provide an interaction with system 100 for changing an existing Payor 
audible menu or similar prompts and instructions for selec- 60 Record with a Temporarily Suspended status field value to 
tion of a transaction or activity via IVR 122. an Active value. As discussed below, the activities shown in 

As seen in FIG. 7, the Payor may preferably choose one FIGS. 8C and 8D are for suspending the entire Payor (i.e. not 
of a number of activities, including selected Payor activities just one particular Child-Payee for a Payor), and for reac- 
(shown in FIGS. 8B, 8D, 8F, 8G, 8H, 81, 8J, 8K and 8L), or tivating the entire Payor. Suspension of individual Child- 
Payor Child-Transfer activities (shown in FIGS. 10A-10I). 65 Payee records is shown in FIGS. 8I-8K, as discussed below. ^ 
As explained below, there may be some activities which are ^V/ The status field value of Temporarily Suspended is uti- " 
not directly available for some of the system's users. For lized to handle situations where a new Payor Record or new 
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Payee Record has been added and the applicable Payor 
Information or Payee Information is being v erified by t he 
Operator. The present system preferably utilizes a Pre-Not e 
process, wh ere , ^a n otice of a change or addition of a 



particular rec ord iSf circulated for review, with instructions 
and/or predefined requirements that thecEange or addition is 
implemented with in_a predetermined number of days (e .g. 
10 days). In this way, a predetermined expiration dat a is 
esta blished for each Pre-Note T and unless the recipient of the 
Pre^ote notifies the Operator of a problem, once the 
expiration date passes, the status of Temporarily Suspended 
is automatically modified in the system to an Active status. 
Temporarily Suspended status may also be implemented as 
shown in FIGS. 8C and 8D to accommodate any variety of 
other temporary situations where a Payor must remain 
inactive temporarily. 
Set Payor Record Status to Permanently Suspended 
FIG. 8E illustrates a situation where an existing Payor 
Record is permanently suspended (i.e. where the Payor is 
not reactivated). In the present system, a Payor Record 
which is Permanently Suspended remains in the on-line files 
160 for a period of time, at which time the record status field 
is changed to a value of Closed, and preferably purged from 
the system at a predet ermined date in t he future. 
Change PIN on a~Payor Record " 
FIG. 8F shows a similar flow chart depicting the equip- 
ment and procedure interaction for changing a PIN for an 
existing Payor Record. Such a change is necessary, for 
example, if security of an existing PIN has been breached. 
Add a Child-Payee Record 

FIG. 8G shows the steps for adding a Child-Payee record. 
As explained in more detail below, the PayorlD is utilized to 
access the Payor Record within the Payor Files maintained 
on system 100 in the on-line files 160. It should be noted that 
on-line files 160 do not necessarily need to be set-up for 
"real-time'* access or use. In fact, in the preferred 
embodiment, they are not utilized in a "real time" applica- 
tion. When a Child-Payee record is added, system 100 
checks the Payee Files to ensure that the Payee to be added 
as a Child-Payee for this particular Payor is an existing 
Payee (i.e., a valid Payee Record exists in the on-line file 
160). If a Payee Record does not exist on system 100, an 
appropriate indicator is provided to the Payor. It is contem- 
plated that Payor request for additions of new Payee Records 
be preferably accomplished through interactive devices. 
^ Also, importantly, when a Chil d-Payee record is added , 
defa ult Payee parameters for the particular Payee are set up 
in the Child-Payee record unless specifically altered by the 
Payor. These parameters include the_default maximum pav- 
me^amount. payment tvpeje.g. Negative or Positive) and 
Mim'mum InTervar~P^rticularly, for each Child-Payee 
record, the Payor may set predetermined parameters and 
preferences, such as the maximum permisabls_SilLData 
amoun t which is automatically paid by system 100-fo r this 
Payee, tuning for initiation of payment of Hills (e.g. 5 days 
prior to due date, etc.), and possibly other variables. Often 
a payor may want to set a different maximum payment 
amount, which is the maximum amount the system auto- 
matically pays for an obligation. Once set up, the Child- 
Payee record is saved in the Payor File and a Log Record 
relating to such Child-Payee record is placed in the Log File 
storage of on-line files 160. 

It is also contemplated that Child-Payee records are 
preferably provided with a payment type field designating a 
Child-Payee as either Negative or Positive. If designated 
Positive the system does not accept and process Bill Data 
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from the applicable Member Payee for the purpose of 
creating Payor Child-Transfers for such Child-Payee of the 
Payor to system 100. Consequently, the Payor has to add, 
either interactively or through a CSR, the information cor- 
responding to the Bill Data a Payor sends to system 100 to 
create a Payor Child-Transfer record whenever the Payor 
wants the system to pay the obligation. If the payment type 
is Negative, the system accept and processes Bill Data from 
the applicable Member Payee or the corresponding data 
from the Payor for the purposes of automatically creating 
Payor Child-Transfers for such Child-Payee. 

For Bills of a fixed amount, it is also contemplated that the 
Child-Payee record contain fields so that necessary Bill Data 
can be added to the applicable Child-Payee record so that 
such Bills may be processed and automatically paid by 
system 100. It should be noted that such Bill Data is added 
to the Child-Payee record only when the payment type is 
Negative. 

It is contemplated that the Child-Payee record contain a 
Child-PayeelD. If the Child-PayeelD is not assigned by the 
Payee or such information is not available when the Child- 
Payee record is initially established, the system assigns a 
unique identifier as the Child-PayeelD. 

Change an Existing Child-Payee Record 

FIG. 8H similarly shows how an existing Child-Payee 
record may be modified or changed by the Payor at any time 
through the interactive devices of the system. 

Set Child-Payee Record Status to Temporarly Suspended/ 
Active 

FIGS. 81 and 8J show Payor activities which allow the 
status of a Child-Payee record to be set by a Payor to 
Temporarily Suspended, and reactivated from Temporarily 
Suspended, respectively, These activities are necessary if, 
for example, a Payor has a dispute with a Payee and wishes 
to suspend payment to that particular Payee until the issue is 
resolved. Upon resolution, the Child-Payee record may be 
returned to the Active status. 

Set Child-Payee Record Status to Permanently Suspended 
FIG. 8K shows another Payor activity which enables the 
status of an existing Child-Payee record to be set Perma- 
nently Suspended by the Payor. This process is performed if, 
for example, a Payor is no longer dealing with a particular 
Payee through the system 100. 

Payor Requests to Become a Customer of a Payee 
Finally, FIG. 8L shows a Payor activity which enables a 
Payor to request to become a new customer of a Payee. 
Obviously this activity is only initiated when the Payor is not 
already a customer of the Payee. This activity does not 
establish the Payee as a valid system Payee for such Payor 
(e.g. no Child-Payee record is established) for Bill payment 
purposes. Establishment of a Child-Payee record for a Payee 
is described above and is illustrated in FIG. 8G. 

This Payor activity is envisioned for use with information 
made available to Payor regarding Payee recurring services. 
For example, Payee service or promotional information may 
be mailed to Payors or presented, preferably interactively, 
through a menu to the Payors. Payors seeking additional 
information may select menu options that result in EDI 
forms or messages being transmitted to Payees through 
Payee mailboxes (described in more detail below) identify- 
ing the Payors that want to receive additional information. 
The menu options may further include one or more options 
that if selected by a payor provides the requiste information 
to the function discussed above for creating Child-Payee 
records for the Payor. The Child-Payee Record in the Payor 
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Information may then be used as a recurring data file of bill where the Payor interactively or through a CSR creates 
data so the bill generator generates Child-Transfer Records Payor Child-Transfer records. As seen in FIG. 10A, a 
at predetermined times for payment of the Payee providing PayeelD is entered along with either a Cbild-PayeelD or 
the service or good on a recurring basis. The payor selects PayorlD depending on whether the request is Member Payee 
the payee service option by sending a payor control message 5 or Payor initiated, to enable the system to access the Payor 
having a selection directive through the payor control inter- File in the on-line files 160. If the referenced Payor Record 
face. The Payee is notified by an EDI form via a Payee exists and is Active, and the Child-Payee record exists and 
mailbox that a Payor has selected a service offered by the is Active, and there is not already a related Payor Child- 
Payee so the Payee may commence the service. For Transfer record in the system, the Bill Data is entered, 
example, the Payee may be a magazine publisher and the 10 including amount and due date. The new Payor Child- 
menu option may be for a recurring monthly magazine. The Transfer record is then processed and added to the Payor File 
recurring data in the Child-Payee Record created after the with a status of Ready for later processing and payment in 
Payor selects the Payee service option is used to generate a accordance with the due data and payment parameters 
Child-Transfer Record each month for the magazine and the established by the Payor, and a Log Record relating to such 
Payee is notified in the Payee mailbox to supply the maga- 15 Payor Child-Transfer record is placed in the Log File storage 
zine to the Payor Thus, once the Payor selected the menu . of on-line files 160. FIG. 10B similarly shows a Payor 
option initiating the magazine subscription, the Payee pub- Child-Transfer activity where an existing Payor Child- 
lished is paid each billing cycle until the Payor takes action Transfer record is changed to reflect updated or corrected 
to terminate payment of a bill or to deactivate the Payee of details. 

that Payor. 20 Set Payor Child-Transfer Record Status 

It should be understood that additional Payor activities FIGS. 10C and 10D illustrate situations where existing 

may be added to the system, and that the particular activities Payor Child-Transfer records are changed in status to Hold, 

described with respect to FIGS. 8A-SL are provided only as or changed back to the status of Ready from a prior status of 

exemplary of the preferred activities. Hold. A Payor may want to place a "hold" on a particular 

Payee Activities 25 Payor Child-Transfer record, as there may be some discrep- 

As discussed above, various Payee activities for entering ancy or dispute over the amount of payment or quality of 

Payee Information (e.g. adding, modifying, or deleting par- services or goods. Setting a particular Payor Child-Transfer 

ticular information from existing Payee Records, or the record to a status of Hold enables the balance of the Payor's 

like),arefllustratedinnGS.9A-9E,andareoir^tlytiedto , n Payor Child-Transfer records to be processed in normal 

the main menu loop shown in FIG. 7. Particularly, FIG. 9A 30 course, while only the disputed payment is held. Once the 

shows the addition of a new Payee Record in a manner reasons for holding the account are resolved, the status can 

similar to the addition of a new Payor Record described be reset to Ready via the procedures of FIG. 10D. 

above with respect to FIG. 8A. As illustrated, a new Payee FIG. 10E illustrates an additional Payor Child-Transfer 

Record is assigned a PayeelD and added to the Payee File in activity wherein the status of an existing Payor Child- 

the on-line files 160 with a status field value of Temporarily 35 Transfer record may be set to Canceled. This situation might 

Suspended pending expiration of the Pre-Note verification occur where goods were returned for credit, or Payor made 

process mentioned above. In addition, a Log Record relating other arrangements for payment of a Bill, and the Payor 

to the new Payee Record is placed in the Log File storage of Child-Transfer record is not needed to pay an obligation, 

on-line files 160. FIG. 9B shows similar procedures as Add a Payor Child-Transfer Record Reversal 

described above with Payor Records for changing existing pj^ iqF illustrates another Payor Child-Transfer activity 

Payee Records. where a Payor utilizes the interactive devices (e.g., digital 

It should be kept in mind that the Payee activities of FIGS. personal computers 112, telephones 120, ATM 150, or 

9A-9E are generally initiated only the Operator, and most interaction with a CSR) through central computer 110 to 

frequently arc entered into system 10 by a CSR via the 45 direct system 100 for reversing the last payment on a Paid 

customer service terminals 132. Again, if changing a Payee Payor Child-Transfer record. As mentioned above, each 

Record entails the alteration of particular critical fields (e.g. Payee has a Provisional Period. When this procedure is 

Payee BankAccountlD or PayeeBankID) the status of the utilized, system 100 accesses the Payor , Eile to locate the 

Payee Record is changed to Temporarily Suspended pending m ost recent Payor Chilg VTransfer record which has been 

the completion of the Pre-Note verification process men- 5Q pa id for a particular Child-Payee. The system must also 

tioned above. FIGS. 9C and 9D show details of activities for a ccess the Payee File from the on-line fi ] esJ60 jo insure that 

setting the status of an existing Payee Record to Temporarily the reversal request is within the applicable Provisional 

Suspended, and reactivating a Temporarily Suspended Period as specified in the Payee Record . Assuming that is 

Payee Record, respectively. Finally, FIG. 9E shows the true, the system jiddsa new Payor Child-Transferj egard, 

activity of setting a Payee Record to the status of Perma- 55 with a status of Ready, to the Payor File with an appropriate 

nently Suspended, where a particular Payee is not longer an negative amount to fully or partially oflset the previous 

active participant in the system. payment. A Lo g .Record relating to such Payor Child- 

As also illustrated in FIG. 7, unscheduled processing Transfer record is placed in the Log File storage of on-line 

activities may include Payor Child-Transfer activities shown files 160. D uring the next batch processing of Payor Child - 

in FIGS. 10A-10I. Payor Child-Transfer records may be 60 Transfer jecdrds. the reve rsal k initiated , with the Uperator 

input into the system from time to time to be paid on behalf Ba jcAccount, Payor BankAccount andPayeeBankAccoun t 

of Payors. hejng credited and/or ^biVr l ar mrrlinplv * 

Add/Change Payor Child -Transfer Records List Payor Child-Transfer Records 

FIG. 10A shows the details of a preferred set of activities FIG. 10G illustrates yet another Payor Child-Transfer 

for interactively adding a Payor Child-Transfer record to the 65 activity, wherein the Payor may request the system to list all 

system. This occurs, for example, when a Member Payee existing Payor Child-Transfers for that particular Payor. This 

contacts a CSR for creating Payor Child-Transfer records or activity enables a Payor to determine Payor Child-Transfers 
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which have been made or which are scheduled to be made, 
so that appropriate status changes or other payment controls 
may be implemented as desired It is contemplated that the 
listing of existing Payor Child-Transfers upon request would 
be appropriately displayed in a "device dependent" manner 
upon request of the Payor. For example, such a request 
implemented by the Payor's digital personal computer 112 
or an ATM (e.g., 150) having a screen display, results in a 
listing displayed on the user's screen, while interaction via 
a telephone 120, or via CSR, results in an audible listing of 
such Payor Child-Transfers. 
Request Interim Statements 

FIGS. 10H-10I illustrate yet another Payor Child- 
Transfer activity wherein a Payor may request an interim 
chronological or categorical statement of Payor Child- 
Transfer records. Although it is contemplated that Payors 
participating in the present system would receive periodic 
statements on a monthly, semi-annual, and/or annual basis, 
it is also preferred that interim statements be available upon 
request. FIGS. 10H-10I illustrate how a Payor interfaces 
with system 10 to obtain an interim statement, which is 
preferably produced by the system via the central computer 
170. 

FIGS. 10J-10Q illustrate a set of Payee Child-Transfer 
activities similar to the Payor Child-Transfer activities' 
described above. However, the Payee Child-Transfer activi- 
ties are only used by, and performed by. the Operator (not the 
Payee or at the Payee's request) and i*ayee Child-Transfer 
records are generally only used by the Operator to recover 



Operator feesfynm the Pay ee for services rendered . FIG. 10J 
shows detailsof the preferred set ot activities lor interac- 
tively adding a Payee Child-Transfer record to the system. 
FIG. 10K similarly shows a Payee Child-Transfer activity 
where an existing Payee Child-Transfer records is changed 
to reflect updated or corrected details. FIGS. 10L and 10M 
illustrate situations where the status filed of an existing 
Payee Child-Transfer record is changed to the value of Hold, 
or changed back to the status of Ready from a prior status of 
Hold. FIG. 10N illustrates an additional Payee Child- 
Transfer activity wherein the status of an existing Payee 
Child-Transfer record may be set to Cancelled, and FIG. 
10O illustrates where a reversal may be made based upon the 
last payment on a Paid Payee Child -Transfer record. FIG. 
10P illustrates another Payee Child-Transfer activity 
wherein a request may be made to list all existing Payee 
Child-Transfer for a particular Payee. Finally, FIG. 10Q 
illustrates the Payee Child-Transfer activity wherein an 
inter im chronological statement of Payee Child-Activity 
records and Payee Child-Transfer records may be generated/ 
Payee Information/Bill Data Processing 
It is also contemplated that Member Payees in the system 
have various unscheduled processing tasks that may occur 
on a periodic (e.g. daily) basis. Communication with system 
100 by Member Payees, whether initiated through a digital 
personal computer or similar data terminal equipment 140, 
via a person-to-person conversation with a CSR, or deliv- 
ered through a written request, is preferably translated into 
one of a set of predefined batch-entered transactions, as best 
illustrated in conjunction with FIGS. 11 and 12A-12E. 

The central computer 110 of FIG. 3 also executes exem- 
plary software modules to, for example, perform (a) data- 
base management functions, (b) file handling batch 
operations, (c) settlement processing, and/or (d) reporting 
functions. In a preferred arrangement, central computer 110 
is a mainframe computer of conventional design including, 
for example, symmetrica] multiple processors with an inter- 
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processor interbus. Database management may be provided 
for retrieval of files for various on-line and off-line manipu- 
lation herein, by any of a number of available products in the 
industry, or custom written for the particular application. 
Additional peripheral equipment (e.g., tape drives, printer, 
conventional mass storage device, and conventional com- 
munications interface/multiplexer) to facilitate communica- 
tions and/or bill paying transactions may also be appropriate 
in many applications, and some examples of such equipment 
are provided herein or are apparent to those skilled in the art. 

In the preferred embodiment, the non-interactive Bill 
Data is communicated to the central computer 110 in EDI 
formats, such as currently specified by the Accredited Stan- 
dards Committee (ASC) X.12 Electronic Data Interchange 
within the American National Standards Institute (ANSI). In 
the event that the Member Payee is unable to communicate 
electronically within the EDI X.12 standard, the central 
computer 110 may preferably translate another formal used 
by the Member Payee into the EDI X.12 format using a data 
re-formatter such as the Vector:Connexion from Sterling 
Software of Dallas, Tex. 

Determination of Necessary EDI Form Processing 
Turning now to FIG. 11, details of a preferred scheme for 
processing the EDI files from the Member Payees are 
shown. Particularly, EDI Forms are preferably received by 
system 100 through the protocol translator 118 and personal 
computer interface 152, whereupon the EDI Forms are 
processed and placed into the system mailbox retained in the 
off-line files 165. A Payee file transfer processor 155 is 
preferably provided to assist with this procedure, and for 
accomplishing any reformatting which may be required. As 
shown in the preferred embodiment of FIG. 11, these 
individual EDI Forms are translated and arranged into one of 
five general predefined batch transactions shown in FIGS. 
12A-12E. 

New Bill Data ~~ 
M Particularly, if the EDI Form contains Bill Data, it is 
preferably processed into the system via a procedure illus- 
trated in FIG. 12A. The central computer 110 for on-line 
transactions accesses the Payor File using the Child- 
PayeelD and the PayeelD. If the EDI Form is rejected 
because the Payor Record is not found or an unprocessed 
Payor Child-Transfer still exists, the EDI Form is stored in 
a temporary working file in the off- fine files 165. Also, if the 
control parameters within the Child-Payee record (e.g. the 
maximum payment amount or the Minimum Interval) are 
not met, a Pa yor Child-Transfe r record is created and added 
to the Eayxir TTIe^tb a Hord"sgtg~Ifnrie~Cfa'iig : Payce 
control parameters are met and the Child-Payee status is 
Active, a new Payor Child- Transfer record is created and. 
added t ol^ffir^a yoTTile with a s tatus of Read y, a nd a 
C hld^Ir^ sferJ ^ RecoTd"is^ l ace"d"in the Log File stora ge 
of on-linTfiles 160. If the Chil^l-Payee status is not Active, 
the status of the new Payor Child-Transfer record is set to 
Hold, and an appropriate notification is sent to the Payor. 
Bill Data Correction 

FIG. 12B shows a flow chart diagram similar to FIG. 12 A, 
illustrating the processing of EDI Forms sent to correct 
previously sent EDI Forms which were used to create Payor 
Child-Transfer records. A correction EDI Form is received 
by the system 100 where, for example, a Member Payee 
made a mistake on a previously forwarded EDI Form, or 
where a change of some sort is deemed necessary. The EDI 
Form is forwarded to system 100 with a code indicating that 
it is a correction of a previous EDI Form from the Member 
Payee. As illustrated in FIG. 12B, if a Payor Record is not 
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found or the Payor (Mid-Transfer record is not found, the Transaction Reference File Processing 

EDI Form is rejected and placed in a temporary working file When any Bank related information (e.g. Payor 

in off-line files 165. Similarly, if the previous Payor Child- Bar^untlD, PayorBankID ^g^™™ °* 

Transfer record has a status field value of Returned or PayeeBankID) used by ^/^^^J^^^ 
Canceled, the repla.ment EDI ^^-J^ 5 Krd?aP^ 

in the temporary working file. The balance of the process ^ lhe validity of such new i^mation. TTiis Pke^ote 

shown in FIG. 12B is substantially the same as show* in £ „ elcctroaic f orm either directly to the 

HG. 12A, however, the notice to the Payor is not required ^ or t0 ^ TCFInterfaceBank, which in turn 

if the Child-Payee status is not Active, as presumably that me p^ote eleclronically to the applicable 
notification was already sent 10 Bank Qnce received by the applicable Bank, the informa- 

Reject/Cancel a Child-Payee tj on m tne Pre-Note is either validated or invalidated. 

FIG. 12C shows the processing of EDI Forms which If the information in the Pre-Note is invalid, the Bank 

^ entail the rejection of cancellation of a Payor by a Member re j e cts the Pre-Note by returning it to the originator within 

Payee. As shown in FIG. 12C, if the Payor Record is found, the per iod and with a reason code (indicating the reason 
and the status of the Child-Payee is Active, the receipt of a 1 me p re _N ote was rejected) as defined by the applicable TCF 

reject/cancel EDI Form from a Member Payee (i.e.Ttf ember 0f omcr arran gement. When the originator (if not the 

Payee initiated) causes the status of a Child-Payee record to operator) receives the rejected items it promptly provides 

be changed to Permanently Suspended, and any Payor the systcm jQO with a file of such items (e.g. electronically 

Child-Transfer records are associated with such Member transmitted from the TCFInterfaceBank to system 100, or in 

Payee have their status similarly updated to Cancelled in the anot her data transfer medium such as magnetic tape or 

Payor File in the on-line files 160. Also, an appropriate magnetic cartridge). The processing of these rejected items 

mailer or other notification may be provided or made ^ considered ^ another set of unscheduled tasks that occur 

available to the Payor. Any records in the Transaction OQ a periodic basis (shown as "TCF Returned Item" in FIG. 

Reference File rejected to such Child-Payee that have not ^ returned item is translated into one of the pre- 

yet expired are deleted from the Transaction Reference File defined batch-entered transactions, as illustrated in FIG. 13. 

in the off-line files 165. This is done to ensure that the status If the ^formation in the Pre-Note is valid, the Bank does not 

of the Child-Payee record remains Permanently Suspended. need to do anything and the Pre-Note expires within the 

Change Child-Payee Record system after expiration of a preset time period (e.g., ten 

FIG. 12D shows the process for handling EDI Forms 3Q days) after it was originated, and the applicable information 

directed to changing specific fields in the Child-Payee record is assumed valid by the system 100. 

in the on-line files 160. Again, if the Payor Record is not When monetary transactions are initiated by the system 

found upon r eceipt of such an EDI chan ge request, or if the ioo, originated by the Operator and/or TCFInterfaceBank, 

status of we" Child-Payee is not Active or Temporarily and processed by the Payor Bank or the Payee Bank (FIG. 
Suspended, the EDI Form is rejected and stored as such in 3S 3), those monetary transactions, like the Pre-Notes described 

a temporary working file in the off-line file 165. Otherwise, above, can also be rejected by one or more of the Banks, 

me applicable Child-Payee fields is updated and saved in the when an item is rejected, it is generally returned to the 

Payor File in the on-line files 160, and an gppr^riate notice originator within the time period and with a reason code 

is sent to the P ayor to document the change . (indicating the reason the item was rejected) as defined by 

"Payor Bill Information " 40 the TCF or other arrangement as applicable. As with rejected 

FIG. 12E shows the process for handling EDI Forms Pre-Notes, the originator (if not the Operator) promptly 

directed to providing Member Payee Bill information to provides the system 100 a file of all such rejected monetary 

applicable Payors. For example, the Member Payee Bill items. 

Information may be sent in response to a request from a A second type of Pre-Note may also be created and sent 
Payor for additional information on a Payee service or good. 4 s by system 100 directly to the Payee. Whenever a new 

Again if the Payor Record is not found upon re ceipt ofs uch Child-Payee record is added (e.g., see FIG. 8G), the system 

an EDI request, or if the status onETChiia^Payee iTnot needs to verify the Child-PayeelD as well as possibly other 

Active or Temporarily Suspended, the EDI Form is rejected information that is provided by the Payor. To do so the 

and stored as such in a temporary working file in the off-line system 100 generates a Pre-Note to the Payee (e.g. see FIG. 
file 165 Otherwise, the EDI Form information is placed on 50 19D), and includes the Pre-Note along with the other record 

the Payee bill file for later processing. and/or information generated for the Payee (e.g. see FIGS. 

TCF Returned Item Processing 19E, 191 and 21 discussed below). The receivmg Payee 

Turning now to FIG. 13, preferred details of how the cither validates or invalidates the information contained . in 

systen^fpre^nt invention processes returned item files is the Pre-Note. If the mformaUon in the Pre-Note is vahd, *e 

fllustrated I simplified form Particularly, returned items are 55 receiving Payee does not need to do ^« the 

Sly received and stored in temporary working files Pre-Note expires upon the expiration of a preset Ume peno^ 

(e g TCF return item file) in the off-line 165 of the inven- (e.g. ten days) after it wasongmated and the CrnW-Pay^ID 

tion As described below/if the item returned appears to be and other applicable information is assumed valid by the 

arLtof ^ 100- If there is some 

noTe/reoort will be generated by the TCFInterfaceBank 60 in the Pre-Note the receivmg Payee rejects the Pre-Note by 

3T23S a^r£n£. Otherw4, the returned transac- returning it within the JfS^J^ 

tion is identified to the Payee or Payor, as appropriate, and with a reason code as defined by system lOOttati^ 

ha^dfedTccordingly. If feTrmnsd^ wh X the ^ oX& ™* rc J cctcd - Gc ^^ a u re f D 

^^^^ is simply a status field in the returned item winch provides 

the Payor^aTVWPayor ^ record aTd an 65 explanatory information regarding the return 

Child-Transfer Log Record is added to the Log File tor A third type of Pre-Note may also be created and sent by 

processing by cental computer 170. the system 100 directly to the Payor. Whenever a Payor 
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Record is added (e.g., see FIG. 8A) or whenever there has the Transaction Reference File is accessed for further 

been a change to either a Payor Record or a related Child- processing, as shown in FIG. 13. 

Payee, the system needs to verify such new Payor informa- Log File Pre-Processing and Warehouse File Processing 

tion with the Payor. This may be accomplished in several ^ ^mud set of preferably periodic scheduled activities 

ways. First, the new Payor information may be provided on 5 ^ referenced in FIG. 5 as main Log File split and warehouse 

a periodic chronological statement which is made available filc processing, which is described in more detail in FIGS, 

to the Payor. The Payor is then responsible for correcting any 16B ^ ^ Generally, over the course of each 

errors in the new Payor Information on system 100. The new p Cr i 0 d, each Log Record is added to the Log File in the 

Payor Information may also be made available to the Payor on -hne files 160. Periodically, and preferably daily, the 

via an separate notice each time Payor information has 10 system iqq neec js to perform additional processing using 

changed. Again, the Payor is responsible for having any these j^g Records. Since the Log File contains both 

errors corrected on system 100. Generally Payor Pre -Notes payment-related Log Records and non-payment-related Log 

alone do not cause the status of a Payor Record or Child- Records, a first pass is preferably made through the Log File 

Payee to change. to split the file into two sub-files ("Log 2 File" and "Log 3 

In addition to the unscheduled transactions that are per- 15 File**, as shown in FIG. 16A). The Log 2 File preferably 
formed within system 100 on a periodic (preferably daily) contains all of the payment-related Log Records (e.g., Child- 
basis, there is also a set of scheduled processing tasks that Transfer Log Records), while the Log 3 File contains all of 
can occur on a periodic (e.g., daily) basis in a specific the non-payment-related Log Records. The segregated Log 
sequence of events. The scheduled tasks are, in a preferred Records are all preferably also saved in an archive Log File 
embodiment, grouped into five defined sets of activities, as 20 which is available in the off-line files 65 for use in research, 
shown in FIG. 5. historical documentation, and periodic statements and 

The first set is referred to as Transaction Reference File reports. This effective segregation is seen best in FIG. 16A, 

processing, and is illustrated in more detail in FIG. 14 and and is preferably implemented by central computer 170. As 

FIGS 15A throuRh 15C. Whenever either a Pre-Note or a seen in FIG. 16B, the enure Log 2 File is then read and each 

moneiary transaction (e.g., initiation of a payment) is sent 25 Child-Transfer U>g Record is used to update the existing 

out of the system, a Transaction Reference Record is written warehouse file (which is a temporary working nle in the 

to the Transaction Reference File noting a predetermined off-line files 165 where all of the Child-Transfer Log 

expiration date. The expiration date is calculated as a preset Records are placed). 

time period (e.g. ten days for Pre-Notes, four days for Once these procedures have been completed, as seen in 

monetary transactions) after the initiation date. If the Bank 30 FIG. 16C, the entire warehouse file is then read and each 

does not return the monetary transaction as a rejected item Child-Transfer Log Record is analyzed. If a Child-Transfer 

within the preset period, or if the Bank or Payee does not Log Record is to be processed "today" and it has a Ready or 

return the Pre-Note as a rejected item within the preset Returned status, then the Child-Transfer Log Record is 

period, the expiration date in the applicable Transaction added to the Log 3 File for imminent processing. If the 

Reference Record is reached and either the monetary trans- Child-Transfer Log Record has a Ready status, but its 

action is assumed as accepted, or the applicable information payment data is scheduled for the future, the Log Record is 

in the Pre-Note is assumed as valid, respectively. added to a new warehouse file for storage until future 

Main Transaction Reference File Processing Routine batch-processing iterations. Any other Child-Transfer Log 

Turning to FIG. 14, the Transaction Reference File pro- « Records may be discarded (U. deleted). Child-Transfer Log 

ces2n7^ Records 0 ° H °" « ^^^^^^ 

by central computer 170. The central computer 170 accesses re mam m the system in the Payor File or Payee F Je T^e 
*e Transaction Reference Files in off-line files 165 and Log 3 File now contains all of the non-payment-related Ug 

Recor^ndall^ 

be processed at that time (i.e. the expiration date is less than 45 to be Processed immediately or today*, 
or equal to today's date), or alternatively added to unexpired Log File Processing 

records in a new Transaction Reference File stored in The third set of preferably daily scheduled activities is 
off-line files 165. If the Transaction Reference Record is to referred to in FIG. 5 as Log 3 File processing, which is 
be processed on that day, the system determines whether the illustrated in more detail in FIGS. 17, 18, and 19A through 
Transaction Reference Record pertains to a Payor, Payee, or 50 19K. Turning to FIG. 17, the main loop of preferred pro- 
Child-Payee Pre-Note. These various procedures are shown cessing parameters for the Log 3 File records is illustrated, 
in FIG. 14, with details of preferred procedures for each where batch mode processing is implemented to handle all 
shown in FIGS. 15A, 15B and 15C, respectively. non-payment related Log Records (i.e. maintenance of the 

Detail Transaction Reference Record Processing system), as well as the Child-Transfer Log Records The 

As seen in FIGS. 15A and 15C, if the Transaction Ref- 55 reader understands that mis is literally where the Payor 
ere^e^orf relates to an expireJPre-Note which pertains Information and Payee mfonuUoo | is V™^£^ 
to the Payor Record or a Child-Payee record of a Payor, the the on-line files and used to update the system and to process 
££2Ec ^ Child-Transfer U>g Records. ^ ™\ «»g e ' ™ 

is updated to Active in the Payor File in on-line files 160. accesses both the on-fine files 160 and off >h« : file sl63 to 
SMarly, as shown in FIG. 15B, a Transaction Reference 60 undertake this periodic Processing, to ^^a 
Record which pertains to an expired Payee Pre-Note causes Payor Record has been added to die system, ^ Process of 
Status of ^applicable Payee Record to be updated to FIG. 19A is implemented, whereby a ispiw ried 
Active in the Payee File. If the Transaction Reference to verify the applicable Payor Information. This I^Note is 
Re^ri ^rtains toTpayor Child-Transfer, no further pro- placed the temporary TCF format origination work file of 
cessing is required, since the applicable Payor Child- 65 off-line files 165. . 
Transfer record already has a Pair status. Had a Payor Similarly, where a Payor has changed a portion of its 
Child-Transfer item been returned within the preset period, Payor Information in the system, FIG. 19B illustrates the 
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nrocess for bandline these changes, including determining positive action by the Payor in order to be processed by the 
SluS!- change^nect the kr* Bank £ system. If the statu, field in the ^^f^fh^ 
Payor BankAccount information. If it docs, a Pre-Note is record or Payee Records are not Active and the ^ Payor 
M to verity the new information. If other Payor Infor- Child-Transfer record is one for Operator fees to be, paid by 
So has been changed which affects a payee in the s die Payor to the ^}^±l^^^J^ 
system, an appropriate EDI Form for delivery to particular Child-Transfer record is ready for payment today, see na 
Payees is provided as appropriate. FIG. 19C illustrates 23A), the system marks the Payor Chfld-Transfen record to 
Droning of Log RecordY which require mailers or other be queued for processing in a predetermined number of days 
So^ ^e of which have been described above. (e.g. five days), and the record . repriced m the Payor Fde 
FIG 19D^Ilus.rate S batch processing of Log Records „ and a new Child-Transfer Lag Record is added to the! Log 
wherein a Child-Payee record has been added which File so that the system retries the processing of ^the Child- 
requires the addition of a Pre-Note to the Payee (i.e. EDI Transfer Log Record for Operator fees later FIG. 191 ako 
Form), as well as an addition of a Traction Reference illustrates the situation where a Payor has ducted a rever 
Record to the Transaction Reference File for future refer- sal of payment" of a Payor Child-Transfer with a status field 
he off-line files 165. „ valueof Paid, but the Transaction Reference Record relating 



FIG. '~S--2?£r ^ ^^^^^-^^ 

sTation, the on-line Payor File with the changed informa- and a new Child-Transfer Log Record is added to the Log 

tion is accessed, an appropriate EDI Form Pre-Note to the File. 

Payee is provided, and a Transaction reference Record is FIG. 19J illustrates the processing of Payee Child- 
bed to L Traction Reference File. FIG. 19F is quite Transfer for various Payees in system 100 
similar to FIG. 19A, and provides the details for processing 25 facilitates the collection of services fees due the Operator for 
STtddMontf a Payee Record and the generation of an services provided to the Payee . The procesang that is 
^ropSre-No.e for verification. FIG. 19G is similar to performed in FIG 19J I fa .much hke that of 191 for Payor 
FIOMC. and applies to processing of Log Records which Child-Transfers. FIG. 19K .Uustrates the processing ^ that is 
require mailers or notices from the system required to properly inform the Payee when a Payor has 
^Aspreviouslydiscussedtheremay^situationsin which 30 »^ V ZZ^^S~& 

processing of such a situation, wherein all Child-Payee purpose. 

records are located from the various Payor Records in order EDI Forms Origination Processing 
to be updated to the Status of Permanently Suspended, and 35 The fourth set of preferably daily scheduled activities is 
the generation of appropriate notification to both Payee and referenced in FIG. 5 as EDI Form processing, and is 
affected Payors described in more detail in FIG. 20. In this portion of the 
FIG 191 illustrates the processing of Payor Child- inventive system, all of the forms written to the EDI F°rm 
TrSsfers for various Payors in the system. This procedure work file are sorted by Payee, are separated m to indivtdua 
facilitates provision of one of the advantageous features of 40 EDI Form files for each Payee and are store I in the 
the overall system, wherein periodic Bill Data in the form of respective Payee's maUbox. In the preferred 
Payor Child-Transfer records are automatically paid to a the Payor Child-Transfer information and Child-Payee 
plurality of Payees on behalf of a Payor, unless that Payor information provided to the Payees is communicated torn 
undertakes positive action to prevent a particular payment the central computer 170 in EDI formats as . «un«Uy spec.- 
from being made, to modify the payment amount, or to 45 fied by the Accredited Standards .Committee .(ASQ X.12 
" ersTa paymen made by the system within an allowed Electronic Data Interchange wuhin the Anaencan National 
SSS As illusLed Jhe central computer 170 Standards Institute (ANSI). In the event that the P^ rs 
accesses the Payor File, Payee File, and Transaction Refer- unable to communicate electronically with the EDI X.12 
IZc File from both the on-line files 160 and the off-line files standard, the central computer 170 can translate the EDI 
165 in order to process the Payor Child-Transfer records and 50 X.12 format to the one used by the Payee using a date 
U, inWate payments. If the Payor Child-Transfer status field re-formatter, such as the VectonConnexton program dis- 
is Ready and the Payor Record status field, Child-Payee cussed above, or make available the information to the 
Record status field, and Payee Record status field are all Payee via other means (e.g., reports). 
Active the Payor Child-Transfer is processed, and a new FIG. 20 also illustrates the accumulation and netting 
Payor Child-Transfer record with a status field having a ss procedures of system 100, wherein all payments and rever- 
value of Paid is added in the Payor File. A record is also sals for a particular Payee are netted so that a single net debit 
created utilizing the Payor BankID and Payor or credit position may be determined for that Payee. This 
BankAccountID, and this information is stored in the tem- single net debit or credit position or amount is used I to 
porary TCF format origination work file. Notification to the generate the settlement message sent to a TCF as described 
Payee of payment is also generated via and EDI Form which so below with reference to FIG. 21. It is contemplated that this 
is stored in the EDI Form work file in the off-lines 165. arrangement may save transaction costs and simplify the 
If the status field in the Payor Record, Child-Payee overall implementation of the system among the ^ various 
Record, or Payee Record status fields is not Active, the status Banks and Payees. The process unrated in FIG. 20 auto- 
field of the Payor Child-Transfer record (if not for Operator matically updates the Payee FJe and TCF format origination 
fees) is set to Hold until that situation is rectified. It should 65 work file with the accumulated amounts when the last record 
be noted that once a Payor Child-Transfer record is placed pertaining to a particular PayeelD has been processed by 
in the Hold status, it is only changed to an Active status by central computer 170. 
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TCF Iiem Origination 

The fifth and final set of preferably daily scheduled 
activities is referred to in FIG. 5 as TCF item origination, 
which is illustrated in more detail in FIG. 21. This process 
simply sorts the records in the TCF format origination work 
file and writes them to an TCF format origination file that 
may be sent (preferably electronically through interactive 
equipment) to the applicable Payor Banks and payee Banks, 
to the applicable TCFs for distribution to Payor Banks and 
Payee Banks and/or to the TcFInterfaceBank for distribution 
to the applicable TCFs. In addition, a corresponding Trans- 
action Reference record for each record sent by system 100 
is written to the Transaction Reference File in off-line files 
165 with a proper expiration date. It is contemplated that a 
Bank may return an item to the applicable originator within 
a predetermined time period (e.g. 24 hours) after receiving 
the item. With the inherent delays in transferring data, the 
system 100 maintains a later expiration date (e.g. four days) 
after the origination date within the Transaction Reference 
File. This is done for several reasons. 

First, if an item is returned, the Transaction Reference File 
is used to identify the PayorlD from which the Payor 
Child-Transfer originated through the use of the reference 
number field. If a Payor attempts to reverse a Payor Child- 
Transfer prior to the expiration date of the related Transac- 
tion Reference Record, the system automatically schedules 
the initiation of such reversal for the next business day 
following such expiration date. This safeguard tends to 
minimize the potential of fraudulent transactions, where a 
Payor could otherwise initiate a Payor Child-Transfer to a 
Payee, then reverse the Payor Child-Transfer returns such 
item unpaid, but the Payor Child-Transfer reversal generates 
a credit to the Payor BankAccount giving the Payor funds to 
which it is not entitled. The expiration date within the 
Transaction Reference Record for each Child-Transfer Log 
Record prevents this scenario from happening. 

Referring to FIG. 21, it is preferred that the TCF format 
origination file be sorted so that items destined for the same 
end point (e.g. destined for the same TCF) are grouped 
together, with the sorted files being temporarily maintained 
in the off-line files 165 as sorted TCF format origination 
work file. As each record from the sorted TCF format 
origination work file is processed, a unique reference num- 
ber is preferably added to the record along with the Payor 
BankID and Payor BankAccountID, or the Payee BankID 
and Payee BankAccountID, as appropriate. The unique 
reference number, along with other necessary information, is 
stored in a Transaction Reference Record in the Transaction 
Reference File for future use, and a monetary transfer of 
funds record compatible with the applicable end point, 
preferably in a standard TCF format such as the National 
Automated Clearinghouse Associations (NACHA) format, 
is added to a new TCF format origination file. Upon comple- 
tion of the daily scheduled processing tasks (e.g., FIG. 5), 
appropriate records are forwarded to the appropriate end 
point to complete the payment transaction, and settle mon- 
etary amounts between and among Payors, Payees and/or 
the Operator. Such forwarding and settlement can be accom- 
plished by sending the TCF format origination file to the 
TCFInterfaceBank which in turn originates such informa- 
tion to the TCF for ultimate distribution to and settlement 
with applicable Banks. It is also contemplated that the 
settlement of funds for Payor Child-Transfer transaction, 
particularly credits to Payees, could be accomplished by any 
number of means such as issuance of a paper check, wire 
transfer, TCF or other arrangements. 
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Other Scheduled Processing Tasks 
In addition to the unscheduled transactions that are per- 
formed within the system on a periodic basis, and the set of 
scheduled processing tasks that occur on a periodic basis, 

5 there is also preferably another set of scheduled processing 
tasks. The scheduled processing tasks are generally grouped 
into five defined sets of activities, as illustrated in FIG. 6. 
Child-Payment fixed Payment Processing 
The first set of scheduled activities Child-Payee fixed 

10 payment processing which is described in more detail in 
FIG. 22. This process is performed periodically (e.g. once a 
week) for those Child-Payee records that have fixed pay- 
ment parameters and a next due date within some pre- 
determined period (e.g. 14 days). This allows generation of 

15 the applicable Payor Child-Transfer records sufficiently in 
advance to permit a Payor to change, modify or cancel such 
Payor Child-Transfer prior to initiation of payment. Only 
those Payors that have a status field value of Active and a 
related Child-Payee status field value of Active are pro- 

20 cessed under this scheduled activity. If a Payor Child- 
Transfer record for the same Payee (e.g. same Child- 
PayeelD) currently exists for the Payor and has a status field 
of Ready or Hold, then the process in FIG. 22 is bypassed 
for such Child-Payee but is considered during the next 

25 periodic fixed payment processing. Once the Payor Child- 
Transfer record is created and added to system 10, the Payor 
Child-Activities shown in FIGS. 10B-10G are available to 
the Payor. 
I Chronological Statement Processing 

30N^ The second set of scheduled activities in_ chronologic al 
^stajejDeuLEIQC^ing, which is described in more detail in 
FIGS. 23A and 23B, and is preferably pe rformed perjqdi- 
call v (e.fr o n a monthb Lb f a s is) o rftajeg ugs t yBased upon the 
statement cvcleAj ech p seq ^b y^e^Sa r Ti^e. the preferred 

35 p eriodic timin g chos en' b~y ine Payor ), this set of tasks are 
performed on days mat facilitate tne creation of the state- 
ment at the proper time. For example, if the Payor elects to 
receive the system statement by the fifteenth of each month, 
then the P ayor selected_sta_tement cycle d ate^naa y cutoff 

40 tran sactions to be mcludedi a.th^ 

ea ch month to ensure that the Payor receives the state ment 
by Jhefifteenth. Additionally, the Payor may request through 
interactive means that a statement be created. The important 
point to note is that only those Payors that have a status field 

45 value of Active, Temporarily Suspended, or Permanently 
Suspended receive a statement. Whenever a Payor Record 
has a status field value of "closed " the system 100 initially 
sets the status field value to Permanently Suspended for the 
Payor Record. After the first statement is generated for each 

50 Payor with a Permanently Suspended status, the status field 
is updated to the Closed value. This mechanism is used to 
ensure that only one statement is generated for a Closed 
Payor Record. This obviates superfluous paperwork once a 
Payor is no longer active, and allow keeping the system's 

55 data bases current. *■ 
As illustrated in FIG. 23A, the central computer 110 reads 
the Payor File to locate all of the Child-Payee Records that 
did not have a status of Closed or Deleted, and accesses the 
Payee File to locate all of the necessary information needed 

60 to provide an understandable and complete periodic state- 
ment of activities. Additionally, the periodic service fee may 
be automatically included with this statement, whether that 
fee is based upon actual transactions, a flat service fee, or a 
combination of flat fee plus service transaction costs. Ser- 

65 vice fee information for the Payor is collected in the Payor 
Child-Activity record which is used to create an appropriate 
Payor Child-Transfer record with a status field value of 
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Ready. The service fee is then debited from the Payor 
BankAccount by the initiation of such Payor Child-Transfer 
record. The information from the Log File, Payor File, and 
Payee File, along with the service fee record is added to the 
Payor's chronological statement work file, which is a tem- 5 
porary work file in the off-line files 165. If the Payor Record 
or Child-Payee Record being processed has a status field 
value of Permanently Suspended, this status field is changed 
in this process to Closed to ensure a final cutoff of statements 
for inactive Payors, as discussed above. 10 

FIG. 23B shows the preferred process and interaction of 
system 100 with apparatus for making available reports (e.g. 
printers, microfiche, imaging equipment, magnetic tape 
devices, etc.). Particularly, the Payor chronological state- 
ment work file is preferably sorted in some predetermined 15 
manner (preferably by zip code and carrier route code to 
minimize mailing costs) to consolidate reports to be mailed 
in a most efficient way. The sorted chronological statement 
work file for the Payor is then printed on-line or downloaded 
for remote printing and such information is made available 20 
to individual Payors. For archival purposes, the Payor state- 
ments are saved such as by microfiche imaging or other 
compressed storage facilities. 

Categorical Statement Processing 

The third set of scheduled activities is categorical state- 25 
ment processing, which is illustrated in more detail in FIGS. 
24A and 24B. This set of processing tasks is preferably 
performed periodically (e.g. at the end of each calendar 
year) or upon request of the Payor, and generates a statement 
for each Payor that has a status field value of Active, 30 
Temporarily Suspended, Permanently Suspended, or 
Closed. After the statement is generated for each Payor with 
a Closed status, the status field is updated to Deleted. This 
mechanism ensures that when purge processing occurs in the 
future, those Payors that have a Deleted status are removed 35 
from the system. FIGS. 24A and 24B similarly comprise 
steps and equipment interfaces which correspond to that 
described in FIGS. 23A and 23B. 

Periodic Statement/Invoice Processing 

The fourth set of scheduled activities is Member Payee 40 
periodic statement/invoice processing, which is illustrated in 
more detail in FIGS. 25A and 25B. On a periodic basis a 
statement may be generated for each Member Payee, listing 
the invoice amount for services provided over the past 
period. Like Payor statements, Member Payee statements 45 
are generated for those Member Payees that have a status 
field value of Active, Temporarily Suspended, or Perma- 
nently Suspended. Whenever a Member Payee Record is 
closed, the system places a Permanently Suspended status 
on the Payee Record. After the statement is generated for 50 
each Member Payee with a Permanently Suspended status 
field value, the system updates the status field value to 
Closed. This mechanism is used to ensure that only one 
statement is generated for a Closed Payee Record. In 
addition, periodically all those Payee Records that have a 55 
Closed status field value are updated by the system to a 
status field value of Deleted. This mechanism ensures that 
when the subsequent purge processing occurs only those 
Member Payees that have a Deleted status field value are 
removed from the system. FIGS. 25 A and 25B similarly 60 
comprise steps and equipment interfaces which correspond 
to that described in FIGS. 23A and 23B. An accounts 
receivable file is preferably shown in FIG. 25A as a tem- 
porary work file in the off-line files 165 as a location for 
storing information for billing users of system 100 for 65 
service fees. For example, this information may be utilized 
for billing Member Payees for service fees and the like. 
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Periodic Record Purge 

The fifth set of scheduled activities is periodic purge- 
records-with-deleted-status processing. This set is not illus- 
trated in any figures due to the optional and relatively simple 
nature of the task. The task comprises a re-organization of 
the database structures such that all Payor Records and 
Payee Records that have a status field value of Deleted, 
including their related Child-Payee and Payor Child- 
Transfer records, are not written to the new re-organized 
database structure. In addition, any Child-Payee Records 
that have a status field value of Deleted, regardless of the 
Payor status, are also not written to the new re-organized 
database structure. 

The reader understands from the detailed discussion 
above, the inventive system and method for automatically 
paying recurring Bills specifically includes selective Payor 
payment and reversal controls which have heretofore been 
unavailable in automatic, or Negative, payment arrange- 
ments. The above-described apparatus and equipment inter- 
faces preferably enable the automatic settling of Bills by 
Payors with a variety of Payees, wherein the system com- 
prises a set of electronically accessible files for receiving 
and at least temporarily storing Payor Information from one 
or more Payors, which preferably includes the name, 
address, Payor BankID, Payor BankAccountID, and prefer- 
ences for Bill Payment timing and statement cycle timing. 
Similarly, Payee Information for Payees is received and 
stored, including allowed Provisional Periods, and Payee 
name, address, Payee BankID and Payee BankAccountID. 

The system also enables ongoing receipt of new and 
modified information, including possibly Payor control 
messages, from Payors, as well as Bill Data from the Payees. 
The payor control messages may include data that corre- 
sponds to the Bill Data received from the Payees. The 
system continually collects both Payor Information and 
Payee Information, and, at least periodically, matches Bill 
Data received by the system with Payor related data to 
establish Bills to be paid and due dates therefore. The system 
automatically pays the established Bills of Payors in accor- 
dance with the corresponding due dates, other Bill Data and 
preferences of each such Payor. Payment of Bills on behalf 
of the Payor to participating Payees is automatic, or 
Negative, and requires no initiation from a Payor, and, in 
fact, is completed unless positive action is initiated by the 
Payor to stop or modify such payment. 

Payors are able to implement additional control over 
otherwise automatic payments by modifying payment tim- 
ing or amounts, placing particular Payor Child-Transfers on 
hold, and/or by reversing payments actually made by the 
system within an applicable Provisional Period established 
by that particular Payee. The present system further auto- 
matically provides statements to Payors and Payees con- 
cerning various Bills which are to be paid, payments and 
charges made, and Bills which have been held and/or 
reversed. As described above, the continual input of infor- 
mation from Payees and Payors can be received in an 
unscheduled manner, while processing of such information 
to update and maintain the system record and to process 
payments and payment reversals in accordance with payor 
control messages provided by such information is preferably 
completed in a predetermined periodic or batch mode man- 
ner. Settling of net payments between Payors and Payees is 
also preferably undertaken in a batch mode manner, 
whereby initiation of net payments to individual Payees may 
be accomplished in single periodic transactions. 

As mentioned at various places above, while a particular 
equipment and apparatus preferred for implementation of 
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the present invention has been set forth in detail herein, it is 
believed that the function and operation of these various 
elements may be achieved by a variety of alternative com- 
binations and equipment arrangements by those skilled in 
the art. Having shown and described the preferred embodi- 5 
ments of the automatic bill paying system and method of the 
present invention, it is contemplated that further adaptations 
of the system and method of the present invention may be 
accomplished by appropriate modifications by one skilled in 
the art without departing from the scope of the present 1Q 
invention. Several of such potential modifications have been 
mentioned, and others will be apparent to those skilled in the 
art. For example, while the payment processing and main- 
tenance portions of the method have been described as 
batch-mode oriented, it may become desirable and/or fea- 5 
sible in some applications to implement these steps in real 
time. Similarly, while it is preferred to provide the on-line 
processing in the form of a computer (e.g. computer 110 
described above) which operates separately from the batch 
processor (e.g. central computer 170 described above)., it is 2Q 
contemplated that these elements might be combined in the 
form of a multiple server system arrangement, or another 
functional unitary setup. Accordingly, the scope of the 
present invention should be considered in terms of the 
following claims, and is understood not to be limited to the ^ 
details of structure and operation shown and described in the 
specification and drawings. 
What is claimed is: 

1. A third-party bill paying system, comprising 

storage for payee information for each of a plurality of 30 
payees, 

storage for payor information for each of a plurality of 
payors, the payor information for a payor identifying a 
plurality of payees authorized by the payor to receive 
transfers of funds from the payor, and control param- 35 
eters defining the manner in which transfers of funds 
are to be performed, 

a payee communications interface receiving for use by the 
third party, bill data from each of said payees, 

a funds transfer interface generating, in the absence of 40 
specific authorization from a payor, one or more elec- 
tronic funds transfer messages from the third party 
transferring funds for the payor and a payee using bill 
data received from the payee, the stored payee infor- 
mation for the payee, the stored payor information for 45 
the payor, and /or the control parameters stored for the 
payor. 

2. The system of claim 1, wherein the stored control 
parameters for a payor identify a maximum amount to be 
transferred between a payor and each of the payees autho- so 
rized by the payor to receive transfers of funds from the 
payor, the funds transfer interface generating an electronic 
funds transfer message for a payor and payee only if the 
amount to be thereby transferred does not exceed the maxi- 
mum amount identified for the payee in the stored control 55 
parameters of the payor. 

3. The system of claim 1, wherein the stored control 
parameters for a payor identify a minimum interval of time 
between generation of electronic funds transfer messages, 
the funds transfer interface generating an electronic funds 60 
transfer message for a payor and payee only if no other 
transfer of funds for the payor and payee occurred during the 
minimum interval of time identified for the payee in the 
stored control parameters of the payor. 

4. The system of claim 1 wherein the stored payor 65 
information includes a financial institution account number 
that corresponds to a government account. 
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5. The system of claim 1 further comprising 

storage for bill records corresponding to generated elec- 
tronic funds transfer messages, and 

a payor communication interface presenting stored bill 
records to a payor so that a payor may review an 
account of fund transfer activity. 

6. The system of claim 5 wherein 

the payor communication interface receives a reversal 
directive from a payor corresponding to a reverseable 
stored bill record, and 

the funds transfer interface responds to the reversal direc- 
tive by generating one or more reverse electronic funds 
transfer message transferring funds from the payee 
identified in the reverseable bill record and to the payor 
identified in the reverseable bill record. 

7. The system of claim 6 wherein 

the payee information identifies a provisional period 
indicating a period of time during which the payor may 
cause a reverse transfer, and 

the funds transfer interface does not respond to a reversal 
directive received from a payor outside of the provi- 
sional period. 

8. The system of claim 1 further comprising 

a payor communication interface receiving a payor con- 
trol message from a payor identifying at least one of a 
payment amount and payment date for a payment to be 
made to and identified payee, and wherein 

the funds transfer interface uses the payment amount or 
payment date identified by the payor control message 
when generating an electronic funds transfer message 
transferring funds for the payor originating the payor 
control message and the payee identified in the payor 
control message. 

9. The system of claim 1 wherein the payee communica- 
tion interface receives a payee control message from a 
payee, and modifies the payee information for the payee 
originating the payee control message in response to the 
content of the payee control message. 

10. A bill paying system, comprising 
storage for payee information, 

storage for payor information for each of a plurality of 
payors, the payor information including control param- 
eters established by payors for controlling transfers of 
funds to a payee from the payor establishing the control 
parameters, 

a funds transfer interface generating electronic funds 
transfer messages causing a transfer of an identified 
amount of funds for an identified payor and an identi- 
fied payee using bill data, the stored payee information 
for the payee, the stored payor information for the 
payor, and/or the control parameters stored for the 
payor, 

a payor communication interface for communicating with 
an interactive device under the control of a payor, the 
payor communication interface causing the interactive 
device to perform a menu driven interactive procedure, 
the interactive procedure including presenting to a 
payor a menu of one or more transactions each repre- 
senting a payee* s bill and identifying an amount of 
funds to be transferred from the payor to the payee in 
payment of the bill, the payor communication interface 
being responsive to the payor's authorization by direct 
entry and selection of an item in the menu representing 
a transaction presented to the payor using tie interac- 
tive device, to deliver bill data to the funds transfer 
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interface and cause the funds transfer interface to 
initiate the funds transfer identified by the transaction 
selected by the payor. 

11. The system of claim 10 wherein the interactive device 
comprises a digital personal computer under the control of 
the payor, and said transactions are presented to a payor on 
a computer display. 

12. The system of claim 10 wherein the interactive device 
comprises a telephone under the control of the payor, and 
said transactions are presented to a payor via the telephone. 

13. The system of claim 10 wherein the interactive device 
comprises an automated teller machine (ATM) under the 
control of the payor, and said transactions are presented to 
a payor on an ATM display. 

14. The system of claim 10 wherein said transactions 
further identify a date by which funds are to be transferred 
from the payor to the payee. 

15. The system of claim 10 wherein the menu driven 
interactive procedure performed by the interactive device in 
response to the payor communication interface further 
includes presenting to the payor a menu of one or more 
functions, and the payor communication interface is respon- 
sive to a payor's selection of a menu item at the interactive 
device to perform the corresponding function. 

16. The system of claim 15 wherein the payor commu- 
nication interface responds to selection of a reversal menu 
item at the interactive device by generating one or more 
electronic funds transfer messages transferring from an 
identified payee and to an identified payor an amount 
previously transferred from the payor to the payee. 

17. The system of claim 10 wherein the control param- 
eters for a payor include a maximum payment amount which 
may be transferred by the funds transfer interface, the 
system preventing transfers of funds which exceed the 
maximum payment amount, and wherein the payor commu- 
nication interface responds to selection of a maximum 
payment menu item at the interactive device by altering the 
maximum payment amount of the payor. 

18. The system of claim 10 wherein the control param- 
eters for a payor include a minimum interval time between 
transfers of funds to a single payee by the funds transfer 
interface, the system preventing a transfer of funds if any 
other transfer of funds for the payor and payee occurred 
during the minimum interval of time identified for the payee 
in the stored control parameters of the payor, and wherein 
the payor communication interface responds to selection of 
a minimum interval menu item at the interactive device by 
altering the minimum interval time for the payor. 

19. A third-party bill paying system, comprising 
storage for payee information, 

storage for payor information for each of a plurality of 
payors, 

a payee communication interface communicating with a 
payee to receive for use by the third party, bill data from 
the payee identifying a payment amount to be trans- 
ferred from a payor to the payee, 

a payor command interface to receive a reversal directive 
from a payor to reverse a payment, 

a funds transfer interface generating, in the absence of 
specific authorization from an identified payor, one or 
more electronic funds transfer messages from the third 
party causing transfer of an identified amount of funds 
from the identified payor and to an identified payee 
using bill data, the stored payee information for the 
payee, and/or the stored payor information for the 
payor, and generating one or more reverse electronic 
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funds transfer messages causing transfer from a payee 
and to a payor an amount of funds previously trans- 
ferred from the payor to the payee in response to a 
reversal directive received from a payor. 
5 20. The system of claim 19 wherein the payee information 
includes an identification of a provisional period of time 
during which the payor may cause a reverse transfer, the 
funds transfer interface not generating a reverse electronic 
funds transfer message in response to a reversal directive 
from a payor received outside of the provisional period. 

21. The system of claim 19 wherein the payor command 

interface comprises a payor communication interface for 

communicating with an interactive device under the control 

of a payor, the payor communication interface causing the 

interactive device to perform a menu driven interactive 

procedure, the interactive procedure including presenting to 

a payor a menu of one or more functions, the payor 

communication interface being responsive to the payor's 

selection of a reversal menu item using the interactive 

device, to deliver a reversal directive to the funds transfer 
20 . ' 
interface. 

22. The system of claim 21 wherein the interactive device 
comprises a digital personal computer under the control of 
the payor, and said transactions are presented to a payor on 
a computer display. 

23. The system of claim 21 wherein the interactive device 
comprises a telephone under the control of the payor, and 
said transactions are presented to a payor via the telephone. 

24. The system of claim 21 wherein the interactive device 
30 comprises an automated teller machine (ATM) under the 

control of the payor, and said transactions are presented to 
a payor on an ATM display. 

25. The system of claim 19 wherein said bill data further 
identifies a date on which funds are to be transferred from 

3S the payor to the payee. 

26. A method of paying bills using a third party, com- 
prising 

storing paying information for each of a plurality of 
payees, 

40 storing payor information for each of a plurality of payors, 
the payor information for a payor identifying a plurality 
of payees authorized by the payor to receive transfers 
of funds from the payor, and control parameters defin- 
ing the manner in which transfers of funds are to be 

45 performed, 

receiving for use by the third party, bill data from each of 
said payees, 

generating, in the absence of specific authorization from 
a payor, one or more electronic funds transfer messages 
50 from the third party transferring funds for the payor and 
a payee using bill data received from the payee, the 
stored payee information for the payee, the stored 
payor information for the payor, and/or the control 
parameters stored for the payor. 
55 27. The method of claim 26, wherein the stored control 
parameters for a payor identify a maximum amount to be 
transferred between a payor and each of the payees autho- 
rized by the payor to receive transfers of funds from the 
payor, an electronic funds transfer message being generated 
60 for a payor and payee only if the amount to be thereby 
transferred does not exceed the maximum amount identified 
for the payee in the stored control parameters of the payor. 

28. The method of claim 26, wherein the stored control 
parameters for a payor identify a minimum interval of time 
65 between generation of electronic funds transfer messages, an 
electronic funds transfer message being generated for a 
payor and payee only if no other transfer of funds for the 
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payor and payee occurred during the minimum interval of 
time identified for the payee in the stored control parameters 
of the payor. 

29. The method of claim 26 wherein the stored payor 
information includes a financial institution account number 
that corresponds to a government account. 

30. The method of claim 26 further comprising 
storing bill records corresponding to generated electronic 

funds transfer messages, and 
presenting stored bill records to a payor sot that a payor 
may review an account of fund transfer activity. 

31. The method of claim 30 further comprising 
receiving a reversal directive from a payor corresponding 

to a reverseable stored bill record, and 
responding to the reversal directive by generating one or 
more reverse electronic funds transfer messages trans- 
ferring funds from the payee identified in the 
reverseable bill record and to the payor identified in the 
reverseable bill record. 

32. The method of claim 31 wherein 

the payee information identifies a provisional period 
indicating a period of time during which the payor may 
cause a reverse transfer, and 

a reversal directive received from a payor outside of the 
provisional period is not responded to. 

33. The method of claim 26 further comprising 
receiving a payor control message from a payor identi- 
fying at least one of a payment amount and payment 
date for a payment to be made to an identified payee, 
and 

using the payment amount or payment date identified by 
the payor control message when generating an elec- 
tronic funds transfer message transferring funds for the 
payor originating the payor control message and the 
payee identified in the payor control message. 

34. The method of claim 26 further comprising 
receiving a payee control message from a payee, and 
modifying the payee information for the payee originating 

the payee control message in response to the content of 
the payee control message. 

35. A method of paying bills, comprising 
storing payee information, 

storing payor information for each of a plurality of payors, 
the payor information including control parameters 
established by payors for controlling transfers of funds 
to a payee from the payor establishing the control 
parameters, 

communicating with an interactive device under the con- 
trol of a payor, causing the interactive device to per- 
form a menu driven interactive procedure, the interac- 
tive procedure including presenting to a payor a menu 
of one or more transactions each representing a payee's 
bill and identifying an amount of funds to be trans- 
ferred from the payor to the payee in payment of the 
bill, and 

responding to the payor's authorization by direct entry 
and selection of an item in the menu representing a 
transaction presented to the payor using the interactive 
device, to generate an electronic funds transfer message 
causing a transfer of an amount of funds from a payor 
to a payee, using the stored payee information for the 
payee, the stored payor information for the payor, the 
control parameters stored for the payor, and/or bill data 
for the transaction selected by the payor. 

36. The method of claim 35 wherein the interactive device 
comprises a digital personal computer under the control of 
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the payor, and said transactions are presented to a payor on 
a computer display. 

37. The method of claim 35 wherein the interactive device 
comprises a telephone under the control of the payor, and 

5 said transactions are presented to a payor via the telephone. 

38. The method of claim 35 wherein the interactive device 
comprises an automated teller machine (ATM) under the 
control of the payor, and said transactions are presented to 
a payor on an ATM display. 

10 39. The method of claim 35 wherein said transactions 
further identify a date by which funds are to be transferred 
from the payor to the payee. 

40. The method of claim 35 wherein the menu driven 
interactive procedure performed by the interactive device 

15 presents to the payor a menu of one or more functions, and 
further comprising responding to a payor's selection of a 
menu item at the interactive device to perform the corre- 
sponding function. 

41. The method of claim 40 further comprising respond- 
20 ing to selection of a reversal menu item at the interactive 

device by generating one or ore electronic funds transfer 
messages transferring from an identified payee and to an 
identified payor an amount previously transferred from the 
payor to the payee. 
25 42. The method of claim 35 wherein the control param- 
eters for a payor include a maximum payment amount which 
may be transferred by the funds transfer interface, and 
further comprising 

preventing transfers of funds which exceed the maximum 
30 payment amount, and 

responding to selection of a maximum payment menu 
item at the interactive device by altering the maximum 
payment amount stored for the payor. 

43. The method of claim 35 wherein the control param- 
35 eters for a payor include a minimum interval time between 

transfers of funds to a single payee by the funds transfer 
interface, and further comprising 
preventing a transfer of funds if any other transfer of 
funds for the payor and payee occurred during the 
minimum interval of time identified for the payee in the 
stored control parameters of the payor, and 
responding to selection of a minimum interval menu item 
at the interactive device by altering the minimum 
45 interval time for the payor. 

44. A method of paying bills using a third party, com- 
prising 

storing payee information, 

storing payor information for each of a plurality of payors, 
50 communicating with a payee to receive bill data from the 
payee for use by the third party, identifying a payment 
amount to be transferred from a payor to the payee, 

generating, in the absence of specific authorization from 
an identified payor, one or more electronic funds trans- 
fer messages from the third party causing transfer of an 
identified amount of funds from the identified payor 
and to an identified payee using bill data, the stored 
payee information for the payee, and/or the stored 
P a y° r information for the payor, and 

receiving a reversal directive from a payor to reverse a 
payment made to a payee, and 

in response to a reversal directive from a payor, generat- 
ing one or more reverse electronic funds transfer mes- 
65 sages causing transfer from a payee and to the payor an 
amount of funds previously transferred from the payor 
to the payee. 
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45. The method of claim 44 wherein the payee informa- 
tion includes an identification of a provisional period indi- 
cating a period of time during which the payor may cause a 
reverse transfer, and further comprising ignoring a reversal 
directive from a payor received outside of the provisional 5 
period. 

46. The method of claim 44 further comprising commu- 
nicating with an interactive device under the control of a 
payor, causing the interactive device to perform a menu 
driven interactive procedure, the interactive procedure 10 
including presenting to a payor a menu of one or more 
functions, and responding to the payor's selection of a 
reversal menu item using the interactive device, by gener- 
ating one or more reverse electronic funds transfer mes- 
sages. 



44 

47. The method of claim 46 wherein the interactive device 
comprises a digital personal computer under the control of 
the payor, and said transactions are presented to a payor on 
a computer display. 

48. The method of claim 46 wherein the interactive device 
comprises a telephone under the control of the payor, and 
said transactions are presented to a payor via the telephone. 

49. The method of claim 46 wherein the interactive device 
comprises an automated teller machine (ATM) under the 
control of the payor, and said transactions are presented to 
a payor on an ATM display. 

50. The method of claim 44 wherein said bill data further 
identifies a date on which funds are to be transferred from 
the payor to the payee. 

***** 
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